Pools — Ganhar rendimento

Visualizar Pool

Adicionar Liquidez

Criar Pool

Suas Posições

Portfólio

Pools — Tela 5 — Revisar e confirmar aporte

Função da tela

Terceira etapa do fluxo de adição de liquidez: apresenta o resumo completo do aporte antes de qualquer assinatura — par, protocolo, faixa, valores exatos, custo total, gas e contexto de IL — e gerencia o fluxo de aprovação de token até a submissão da transação. Foco em iniciante que nunca assinou uma transação DeFi de LP; intermediário como segundo perfil que quer confirmar números antes de assinar.

Componentes / elementos

Estrutural (define o paradigma da tela)

Stepper de progressão (contexto imutável)
- ✓ Passo 1 de 3: Par e protocolo
- ✓ Passo 2 de 3: Faixa e valores
- → Passo 3 de 3: Revisar e confirmar (atual)
- Passos 1 e 2 com ✓ são clicáveis para voltar e editar — sem destruição de estado dos outros campos. Tap no Passo 2 retorna para pools-04 com todos os valores preservados.
Chip-strip de saúde do pool (persistente, herdado de pools-02 e pools-04)
- Rend. est. (7d) 12,4% · TVL R$ 135 M · Vol. 24h ↑1,3%
- Esta é a última tela onde o usuário pode reverter a decisão sem custo on-chain. A saúde do pool deve estar visível.
- Cor e comportamento idênticos às telas anteriores (neutro/âmbar/vermelho conforme estado do pool).

Resumo do aporte (componente principal, leitura antes da assinatura)

Card estruturado com todas as decisões tomadas no fluxo:

┌─ VOCÊ VAI ADICIONAR ───────────────────────────┐
│                                                  │
│  Par         ETH / USDC                         │
│  Protocolo   Concentrado num range (V3)          │
│  Fee tier    0,05%                              │
│  Faixa       ±10% do preço atual                │
│              R$ 16.689 – R$ 20.397              │
│                                                  │
│  ┌─ ETH ───────────────────────────────────┐   │
│  │  1,17 ETH                               │   │
│  │  ≈ R$ 21.695                            │   │
│  └─────────────────────────────────────────┘   │
│                                                  │
│  ┌─ USDC ──────────────────────────────────┐   │
│  │  R$ 21.695,00                           │   │
│  └─────────────────────────────────────────┘   │
│                                                  │
│  Total em tokens       ≈ R$ 43.390             │
│  Gas estimado          ≈ R$ 8,40               │
│  ─────────────────────────────────────────      │
│  Total da operação     ≈ R$ 43.398,40          │
│  (Timestamp: 14:32 · preço pode variar)        │
│                                                  │
└──────────────────────────────────────────────────┘

Cada valor em R$ com locale PT-BR (vírgula decimal, ponto milhar).
Gas em R$ — nunca em GWEI.
Timestamp do cálculo: "Preços às 14:32 · podem variar até a confirmação."
Link "Editar ▾" discreto ao lado de cada seção (Par/Protocolo, Faixa, Valores) — navega diretamente para o passo de origem sem destruir o restante.

Lembrete de IL contextual (educação no ponto de commit — Pilar 4)
- Bloco compacto abaixo do resumo — não um modal, não um banner de aviso. Texto condicional:
  - Faixa não-total (±10% ou ±5%): "Lembrete: se o preço de ETH sair da faixa R$ 16.689–R$ 20.397, sua posição para de gerar rendimento até você ajustar. Isso não é perda de capital — é pausa no rendimento."
  - Faixa total: "Posição não tem expiração. Rendimento gerado enquanto houver volume no pool."
- Link: "Ver simulação de IL →" — abre bottom sheet com simulador simplificado (tabela: se ETH cair/subir X%, você ganha/perde Y%).
- O bloco não tem botão de fechar — é informação, não popup. Se o usuário rolar, passa por ele. Tamanho máximo: 3 linhas de copy + link.
Fluxo de aprovação de token (gestão inline do fluxo ERC-20 approve → LP mint)

O fluxo de aprovação é dividido em etapas visuais explícitas — não surpresa de "popup na carteira":

Etapa A — Aprovação de ETH (quando necessária)
- Card de aprovação compacto: "Passo 1 de 2: Permitir que o protocolo use seu ETH"
- Sub-copy: "Você vai assinar uma aprovação na sua carteira. Essa ação não move ETH — apenas concede permissão ao contrato."
- CTA: "Aprovar ETH" (outline, não preenchido — é pré-requisito, não a ação final).
- Quando ETH já aprovado: ✓ "ETH aprovado" em verde — cartão compacto, não destaque.
Etapa B — Aprovação de USDC (quando necessária)
- Idêntica à Etapa A para USDC.
- Quando USDC já aprovado: ✓ "USDC aprovado" em verde.
- Tokens com aprovação existente (allowance suficiente): etapa não aparece — não exibe passo irrelevante.
Etapa C — Confirmar aporte (CTA final)
- Só aparece ativo quando todas as aprovações necessárias estão concluídas.
- CTA: "Confirmar aporte" — preenchido, cor de destaque.
- Não é vermelho/destrutivo (ação de aporte é reversível via remoção de liquidez).
- Quando aprovações pendentes: CTA está visível mas com estado de "aguardando" com microcopy: "Conclua as aprovações acima para confirmar."
CTA principal (sticky rodapé em mobile, inline em desktop)
- "Confirmar aporte" — ativo após todas as aprovações necessárias.
- Quando pressionado: inicia o flow de assinatura na carteira (Metamask, WalletConnect, etc.) → animação de loading + microcopy: "Aguardando sua assinatura na carteira…"
- Não esconde o CTA durante a espera — usuário pode ver que o sistema está aguardando, não travado.

Cosmético (polish, vai depois do estrutural)

Linha de "Você está fornecendo liquidez em" acima do resumo — frase de contexto intencional para reforçar o ato antes do número.
Ícone de cadeado discreto no header do card de resumo — sinaliza que os dados são do snapshot atual, não editáveis nesta tela diretamente.
Link "Ver detalhes do pool" — abre pools-02 em nova aba (não navega para fora do fluxo).

Regras de negócio

Imutabilidade do resumo nesta tela: valores e faixa mostrados aqui são os decididos em pools-03 e pools-04. Edição via links "Editar ▾" retorna para o passo correspondente e traz o usuário de volta para pools-05 após a mudança, com os valores atualizados. Nunca re-calcular silenciosamente por variação de preço sem avisar — se preço mudou > 2% desde a abertura de pools-05, banner: "O preço mudou desde que você abriu esta tela. Valores atualizados." com CTA "Rever valores" (volta para pools-04) e "Continuar assim mesmo".
Aprovações ERC-20: verificar allowance atual antes de exibir as etapas de aprovação. Se ETH tem allowance ≥ valor do aporte, não exibir o passo de aprovação de ETH — não forçar transação desnecessária.
Sequência de aprovações: ETH primeiro, USDC segundo, LP mint último — sequência linear, não paralela. Se aprovação A falhar, B e C não aparecem no estado ativo.
Aprovação de valor exato vs infinita: default = aprovação pelo valor exato do aporte (não aprovação infinita — Pilar 3, Tier 2). Aprovação infinita disponível em "Configurações avançadas" com aviso: "Aprovação infinita concede acesso permanente ao contrato para este token. Use com cuidado." Não é CTA de primeiro nível.
Gas estimado: recalcula a cada 30s. Se gas subir > 50% desde a abertura da tela: badge âmbar + "Gas aumentou significativamente. O total estimado foi atualizado."
Timestamp de preços: todos os valores derivam do mesmo snapshot (mesma garantia arquitetural de pools-02). Timestamp visível no rodapé do card de resumo. Se snapshot > 60s: banner: "Preços desatualizados. Atualizando…"
Preço mudou durante a revisão (> 2%): banner não bloqueante — não impede a confirmação, mas informa: "O preço mudou desde que você abriu esta tela. Valores atualizados." com opção de revisar.
Pool morta (Vol/TVL < 0,01): chip-strip em âmbar + no resumo, abaixo do rendimento estimado: "Pool com atividade baixa — rendimento estimado pode não se confirmar." Não bloqueia o aporte.

Estados não-triviais

Estado	Comportamento
Loading — carregando resumo	Skeleton em todos os campos do card + chip-strip. Label: "Preparando resumo do aporte ETH/USDC…"
Preço moveu > 2%	Banner não bloqueante: "O preço mudou desde que você abriu esta tela. Valores atualizados." + CTA "Rever valores" (volta para pools-04) e link "Continuar assim mesmo".
Aprovação ETH pendente	Card Etapa A destacado; Etapa B e CTA final em estado "aguardando", visíveis mas inativos.
Aprovação ETH assinada — aguardando confirmação on-chain	Card Etapa A com spinner + "Confirmando aprovação de ETH…" Etapa B e CTA ainda inativos.
Aprovação ETH confirmada	Card Etapa A com ✓ verde + "ETH aprovado." Card Etapa B entra em estado ativo.
Aprovação falhou	Card da etapa com ✗ vermelho + "Aprovação não concluída. Você pode tentar de novo ou ajustar o gas em Configurações avançadas." CTA "Tentar de novo" inline no card.
Aprovação rejeitada na carteira	"Aprovação cancelada. Você precisa aprovar o token para continuar." CTA "Tentar de novo" inline.
Confirmação do aporte assinada — aguardando mineração	CTA principal mostra spinner + "Transação enviada. Aguardando confirmação…" Banner discreto: "Você pode fechar esta tela — sua posição aparecerá em 'Minhas posições' quando confirmada."
Confirmação rejeitada na carteira	"Transação cancelada. Nenhum fundo foi movido." CTA "Tentar de novo" disponível.
Gas insuficiente	Erro inline: "Gas insuficiente para executar. Aumente a tolerância em Configurações avançadas." CTA "Ajustar gas" abre configurações avançadas.
Rede trocou durante o fluxo	Banner bloqueante: "Você trocou de rede. Esta posição é em [rede original]. Mude de volta para continuar." CTA "Mudar para [rede]".
Transação confirmada	Navega automaticamente para pools-06.
Transação revertida on-chain	Navega para pools-06 no estado de falha — ver pools-06.
Sem wallet	(Não deveria chegar aqui sem wallet — mas se ocorrer) Banner bloqueante: "Carteira desconectada. Reconecte para continuar." + CTA "Conectar carteira".

Microcopy crítico (PT-BR)

Elemento	Texto
Breadcrumb	Ganhar rendimento › ETH/USDC › Adicionar liquidez
Título implícito	Passo 3 de 3: Revisar e confirmar
Frase de contexto	Você está fornecendo liquidez em
Label protocolo no resumo	Concentrado num range (V3)
Label faixa no resumo	±10% do preço atual
Faixa em preços absolutos	R$ 16.689 – R$ 20.397
Label gas	Gas estimado
Label total	Total da operação
Timestamp no resumo	Preços às 14:32 · podem variar até a confirmação
Link editar	Editar ▾
IL reminder — faixa não-total	Lembrete: se o preço de ETH sair da faixa R$ 16.689–R$ 20.397, sua posição para de gerar rendimento até você ajustar. Isso não é perda de capital — é pausa no rendimento.
IL reminder — faixa total	Posição não tem expiração. Rendimento gerado enquanto houver volume no pool.
Link simulador IL	Ver simulação de IL →
Aprovação Etapa A	Passo 1 de 2: Permitir que o protocolo use seu ETH
Sub-copy aprovação	Você vai assinar uma aprovação na sua carteira. Essa ação não move ETH — apenas concede permissão ao contrato.
CTA aprovar	Aprovar ETH
Estado aprovado	✓ ETH aprovado
Aprovação infinita (avançado)	Aprovação infinita concede acesso permanente ao contrato para este token. Use com cuidado.
CTA final desabilitado	Conclua as aprovações acima para confirmar.
CTA final ativo	Confirmar aporte
Assinatura pendente	Aguardando sua assinatura na carteira…
Tx enviada	Transação enviada. Aguardando confirmação…
Aviso tx enviada	Você pode fechar esta tela — sua posição aparecerá em 'Minhas posições' quando confirmada.
Erro de aprovação	Aprovação não concluída. Você pode tentar de novo ou ajustar o gas em Configurações avançadas.
Aprovação rejeitada	Aprovação cancelada. Você precisa aprovar o token para continuar.
Tx cancelada	Transação cancelada. Nenhum fundo foi movido.
Preço desatualizado	Preços desatualizados. Atualizando…
Preço moveu	O preço mudou desde que você abriu esta tela. Valores atualizados.
CTA revisar valores	Rever valores
CTA ignorar mudança de preço	Continuar assim mesmo
Gas subiu	Gas aumentou significativamente. O total estimado foi atualizado.
Pool morta — aviso no resumo	Pool com atividade baixa — rendimento estimado pode não se confirmar.
Gas insuficiente	Gas insuficiente para executar. Aumente a tolerância em Configurações avançadas.
Rede trocada	Você trocou de rede. Esta posição é em [rede original]. Mude de volta para continuar.

Rastreabilidade obrigatória

🟢 Herdado

Chip-strip de saúde persistente nesta tela: contexto de APR, TVL e Vol. visível no momento do commit de capital — última oportunidade de reverter sem custo on-chain. Fonte: [uniswap/_consolidado/visualizar-pool.md § Oportunidade — Contexto persistente no ato de operar].
Sinalização de risco in-place sem friction transacional: IL reminder é informação contextual no corpo da tela, não popup de bloqueio; badge de pool morta aparece no resumo sem bloquear o aporte. Fonte: [uniswap/_consolidado/visualizar-pool.md § Insight — Sinalização de risco/variação in-place].
Presets chips não aparecem nesta tela — valores são confirmação, não edição. Se o usuário quer editar, usa "Editar ▾". Consistência com o padrão: chips de percentual existem onde há input de decisão, não onde há confirmação. Fonte: [uniswap/_consolidado/visualizar-pool.md § Insight — Presets chips em qualquer decisão financeira] (herança do princípio, não do componente).
Timestamp unificado de dados: todos os valores derivam do mesmo snapshot. Se snapshot > 60s, banner informa. Fonte: [uniswap/_consolidado/visualizar-pool.md § Fricção — Métricas vivas sem âncora de snapshot].
Gas em R$: nunca em GWEI. Fonte: [pancake-final § Pilar 5 — Localização BR/LatAm como infraestrutura].
CTA desabilitado com label contextual nas aprovações pendentes: nunca cinza mudo. Fonte: [pancake-final § Pilar 2 — CTA dinâmico] + [uniswap-final § Insight — Estados como instrução acionável].
Stepper com passos anteriores clicáveis para edição sem destruição de estado. Fonte: [uniswap/_consolidado/nova-posicao.md § Insight — Stepper pedagógico e contextual].
Fluxo de aprovação ERC-20 inline (não surpresa): sequência de aprovações explicitada antes do CTA final, cada etapa com sub-copy explicando o que acontece na carteira. Fonte: [pancake-final § Pilar 3 — Defesa em camadas].

🔴 Corrige

Fricção — Ausência de estado do pool na janela de decisão de aporte: chip-strip persistente nesta tela + aviso de pool morta inline no resumo. [uniswap/_consolidado/nova-posicao.md § Fricção — Ausência de estado do pool destino].
Fricção — Unidade técnica sem tradução para intuitiva: gas em R$; valores em R$ com eyebrow em token onde relevante; preços em locale PT-BR. [uniswap/_consolidado/visualizar-pool.md § Fricção — Unidade técnica não traduzida para intuitiva].
Fricção #2 — i18n parcial: todo copy desta tela em PT-BR; formato numérico locale BR (R$ 43.398,40, não $43,398.40). [pancake-final § Fricção 2 — i18n parcial].
Fricção — Desacoplamento widget↔contexto no ato de decidir: esta tela mantém chip-strip de saúde e IL reminder visíveis mesmo durante o fluxo de aprovação — as métricas do pool nunca ficam atrás de um overlay. [uniswap/_consolidado/visualizar-pool.md § Fricção — Desacoplamento widget↔contexto].
Fricção — Affordance sem estado honesto: aprovações inativos visíveis mas com estilo de "aguardando" + microcopy contextual — não ficam cinzas mudos nem parecem habilitados quando não são. [uniswap/_consolidado/visualizar-pool.md § Fricção — Affordance sem estado honesto].

🟡 Captura

Pilar 4 — Transparência financeira total antes do commit: resumo estruturado com par, protocolo, faixa, valores por token, gas, total em R$ e timestamp — nenhum número surpresa na carteira. [pancake-final § Pilar 4]. Hipótese: usuário que vê o total em R$ nesta tela antes de confirmar tem 3x menos chance de cancelar a aprovação ao ver o número na carteira — elimina abandono por "susto de valor".
Pilar 4 — Educação contextual no ponto de commit: IL reminder inline (não depois da confirmação) + link para simulador. [pancake-final § Pilar 4] + [uniswap/_consolidado/pools.md § Oportunidade — Sistema pedagógico de métricas DeFi]. Hipótese: usuário que lê "pausa no rendimento — não perda de capital" antes de confirmar não interpreta posição expirada como bug ou perda — reduz tickets de suporte.
Pilar 3 — Defesa em camadas sem paternalismo: fluxo de aprovação explicitado antes do CTA final; aprovação por valor exato como default (não infinita); aviso de mudança de preço não bloqueante. [pancake-final § Pilar 3]. Hipótese: usuário iniciante que entende "essa ação não move ETH" na aprovação ERC-20 tem mais confiança no produto e taxa de abandono na etapa de aprovação cai.
Pilar 5 — Localização BR/LatAm: valores em R$ com locale correto em toda a tela, incluindo gas e total. [pancake-final § Pilar 5]. Hipótese: usuário BR que vê "R$ 43.398,40" como total da operação toma decisão na moeda que entende sem conversão mental.

⚪ Novo

Aprovação por valor exato como default (não infinita, com aviso em avançado para quem quiser). Não está explicitamente documentado nos relatórios de concorrentes como diferencial — os relatórios focam na presença/ausência do fluxo de aprovação, não na granularidade do valor. Justificativa: aprovação infinita é padrão da indústria por conveniência mas é risk surface real para o LP iniciante (contrato com allowance infinita de USDC é risco permanente se o contrato tiver bug). Default por valor exato segue Pilar 3 (defesa em camadas, Tier 2 de proteção de preferência — não precisa de type-to-confirm, mas não é o caminho de menor fricção). Risco: adiciona 1 transação extra de aprovação a cada novo LP entry quando o valor for diferente do anterior. Mitigação: verificar allowance antes — se já aprovado acima do valor, não exige nova aprovação. Evidência futura a coletar: taxa de usuários que mudam para aprovação infinita nas configurações avançadas.
Aviso de mudança de preço com dois CTA ("Rever valores" vs "Continuar assim mesmo") em vez de bloqueio automático ou re-cálculo silencioso. A fricção de "preço moveu durante o review" não está documentada nos relatórios como padrão tratado. Justificativa: re-calcular silenciosamente viola transparência (Pilar 4); bloquear até o usuário revisar viola soberania (A3); oferecer dois CTAs claros respeita ambos. Risco: usuário que ignora "Rever valores" pode confirmar aporte com valores ligeiramente diferentes do que viu — aceitável porque o valor final na carteira é o correto, não o snapshot desatualizado. Evidência futura: taxa de uso de "Rever valores" vs "Continuar assim mesmo" para calibrar se o aviso é necessário ou se vale apenas atualizar silenciosamente com um toast.

Trade-offs e segunda ordem

Fluxo de aprovação inline (2 aprovações + 1 confirmação = potencialmente 3 assinaturas na carteira em sequence) pode causar fadiga de aprovação. Mitigação: verificar allowance existente antes de exibir as etapas — se já aprovado, a etapa não aparece; o caso mais comum (reuso de allowance) vira 1 assinatura apenas.
IL reminder inline (não colapsável) adiciona texto ao corpo da tela. Se o texto for longo, pode empurrar o CTA de confirmação para fora da viewport em mobile — garantir que o CTA seja sticky no rodapé independentemente do comprimento do conteúdo.
Aprovação por valor exato exige mais transações de aprovação do que aprovação infinita — custo de gas real para o usuário. Copy deve ser claro sobre o motivo: "Aprovamos apenas o valor deste aporte por segurança."
Timestamp de preço requer sincronização com o mesmo snapshot de pools-04 — se o backend usa timestamps diferentes entre as telas, os valores podem divergir. Custo de observabilidade arquitetural.
Aviso de mudança de preço implica polling do preço enquanto o usuário está em pools-05 — custo de request em background. Polling a cada 30s é suficiente e não é custoso; mas requer gestão de lifecycle do polling quando a tela sai do foco (parar quando minimizado, retomar quando volta ao foco).
i18n de todos os labels desta tela inclui valores numéricos que variam (R$ 43.398,40 — não é string estática). Formato numérico PT-BR exige Intl.NumberFormat com locale pt-BR em todo o frontend. Custo de implementação real.

Criar Pool — Tela 01: Seleção de par e escolha do modo de provisão

1. Função da tela

Permite que o usuário declare o par de tokens que deseja prover liquidez e, com base nessa escolha, entenda e selecione o modo de provisão adequado ao seu perfil — sem precisar conhecer nomenclatura técnica de protocolo. Foco: iniciante (prioridade) e intermediário.

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

2.1 Seletor de par (Token A / Token B) Dois campos de busca de token em linha horizontal. Token A pré-selecionado com o token base da rede ativa (ex: ETH em Ethereum, BNB em BNB Chain) — default do caso 90%. Token B em branco.

Cada campo exibe:

Ícone + símbolo do token + badge de tipo de emissão ("Canônico", "Wrapped", "Pegged via Binance")
Saldo disponível na wallet abaixo do campo (se carteira conectada)
Ao abrir a busca: lista com seção "Sugeridos" (tokens frequentes do usuário → trending da rede ativa → trending global) e campo de busca livre

2.2 Cards de modo de provisão (aparece após par válido selecionado) Três cards horizontais — um por modo. Cada card contém:

Label primário em verbo de benefício (Pilar 1)
Subtítulo em 1 frase explicando o que o usuário precisa fazer
Badge "Recomendado para você" no card sugerido pelo sistema
Indicador de nível de gestão: chip "Passiva" / "Gestão ativa" / "Configuração técnica"
Nome técnico como secondary label discreto abaixo (tooltip opcional)

Modos:

Label primário	Subtítulo	Chip gestão	Secondary
"Simples — depositar e esquecer"	"Deposite e receba taxas automaticamente. Sem ajustes necessários."	Passiva	V2
"Concentrada — mais retorno, mais atenção"	"Defina uma faixa de preço. Retorno maior enquanto dentro da faixa."	Gestão ativa	V3
"Programável — controle total"	"Configure regras personalizadas com lógica de hooks."	Configuração técnica	V4

O card "Simples" é selecionado por default para carteiras sem histórico de LP ou com primeiro acesso ao fluxo. Para carteiras com histórico de LP concentrado, o card "Concentrada" é pré-selecionado.

2.3 Card de saúde do pool (aparece após par + modo selecionados) Card inline abaixo dos cards de modo. Comportamento:

Pool existente e saudável (TVL alto, Volume 24h ativo): colapsado por default com label "Ver detalhes do pool ▾"
Pool existente inativo (APR ≈ 0%, Volume 24h ↓ > 70% vs 30d): expandido forçado com badge amarelo ⚠ "Pool pouco ativo"
Pool inexistente (novo par): expandido forçado com banner azul "Você será o primeiro provedor — você define o preço inicial"

Conteúdo quando expandido:

TVL atual
Volume 24h + variação vs ontem (seta colorida)
APR estimado (taxas 7d anualizado) com tooltip "Estimativa baseada nas taxas cobradas nos últimos 7 dias. Varia com volume e impermanent loss."
Badge de atividade: "Ativo" (verde) / "Pouco ativo" (amarelo) / "Inativo" (cinza) / "Novo" (azul)

2.4 CTA dinâmico Botão primário na base da tela. Muda de label conforme o preenchimento:

Sem par: "Selecionar os tokens" (disabled)
Par selecionado, modo não escolhido: "Escolher o modo de provisão" (disabled)
Par + modo selecionados: "Configurar minha posição" (enabled, azul primário)
Carteira não conectada: "Conectar carteira para continuar" (enabled, abre drawer de conexão antes de avançar)

Cosméticos (polish posterior)

2.5 Stepper de progresso — 2 etapas visíveis no topo: "1 Configurar" (ativa) → "2 Confirmar". Labels fixos para todos os modos (não mudam com o modo, pois a Kotai já não usa nomenclatura técnica no stepper).

2.6 Breadcrumb + ação "Redefinir" — "Ganhar rendimento / Criar posição" + link "Redefinir tudo" que limpa par, modo e configurações.

3. Regras de negócio

RN-01 — Default de Token A por rede ativa. Token A = token nativo da rede ativa (ETH em Ethereum, BNB em BNB Chain, etc.). Carteira sem rede detectada: Token A em branco. Mudança de rede no header: Token A reseta para novo nativo; Token B persiste se disponível na nova rede.

RN-02 — Token A ≠ Token B. Ao selecionar Token B igual a Token A, Token B reseta para branco com aviso inline "Selecione um token diferente de [Token A]".

RN-03 — Recomendação de modo por heurística de par.

Par com ambos os tokens de stablecoin conhecidos (ex: USDC/USDT, DAI/USDC): badge "Recomendado" vai para "Simples".
Par com token nativo + stablecoin (ex: ETH/USDC) com TVL > $500K: badge vai para "Concentrada".
Par com token nativo + token volátil: badge vai para "Concentrada".
Par exótico sem histórico ou TVL < $10K: badge vai para "Simples" + nota "Para pares novos, a provisão simples é mais segura até o pool ganhar profundidade."
Par sem heurística mapeada: badge vai para "Simples" como default conservador.

RN-04 — Card de saúde do pool: trigger de carregamento. Ao completar par + modo: dispara consulta de estado do pool. Loading state por até 5s. Após 5s sem resposta: exibe mensagem de fallback com opção de retry.

RN-05 — Pool novo: detecção e bloqueio de avanço sem aviso. Se par+modo resultar em pool inexistente e o usuário clicar em "Configurar minha posição" sem expandir o card de aviso, o card é auto-expandido e o botão fica enabled apenas após o usuário rolar até o card (scroll sentinel). Não exige confirmação formal aqui — o aviso completo vem na Tela 03.

RN-06 — Modo "Programável" (V4): barrier de entrada. Ao selecionar o card "Programável", um tooltip/inline banner aparece abaixo: "Este modo é para usuários avançados. Você pode começar com 'Simples' e migrar depois." CTA primário não muda — não bloqueia o avanço, apenas informa. Não usa type-to-confirm aqui (essa ação não é Tier 1 — é configuração reversível; type-to-confirm ocorre na Tela 03 se hooks estiverem ativos).

RN-07 — Validação par↔modo. Se par detectado como "pares correlacionados" (ex: USDC/USDT, stETH/ETH) e modo "Concentrada" ou "Programável" selecionado: nenhum bloqueio. Se par detectado como "par estável" e modo "Simples" selecionado: sem alerta (V2 para par estável é tecnicamente válido, APR menor que V3 mas sem gestão). Alerta ativo apenas quando a combinação implica perda estrutural provável: par volátil exótico com liquidez inexistente em modo "Concentrada" → "Este par tem histórico de baixo volume em provisão concentrada. A provisão simples pode ser mais adequada."

RN-08 — Propagação de estado para Tela 02. Par + modo + fee tier (se V3/V4) + estado do pool (existente/novo/inativo) propagam para Tela 02 via URL parametrizada: /criar-pool?tokenA=ETH&tokenB=USDC&modo=concentrada&fee=3000&chain=1.

4. Estados não-triviais

Vazio (sem par selecionado): Tela com dois campos de par em branco. Cards de modo não aparecem. CTA "Selecionar os tokens" cinza desabilitado. Microcopy acima dos campos: "Escolha os tokens para começar."

Loading (buscando estado do pool após par+modo): Skeleton no lugar do card de saúde — 3 linhas de placeholder animado. CTA muda para "Verificando pool..." (enabled mas desabilitado funcionalmente, com spinner inline). Após 5s sem resposta: "Não conseguimos verificar o estado deste pool. [Tentar de novo] ou [Continuar mesmo assim]."

Pool existente saudável: Card colapsado com label "Ver detalhes do pool ▾". CTA ativo. Nenhum aviso adicional.

Pool existente inativo (APR ≈ 0%, Volume ↓ > 70%): Card expandido com badge ⚠ "Pool pouco ativo". Texto: "Este pool tem baixo volume recente. Você pode ganhar menos taxas e ter mais impermanent loss sem compensação. [Ver detalhes ▾]". CTA continua ativo — não bloqueia; informa.

Pool novo (par+modo sem pool existente): Card expandido com banner azul "Você será o primeiro provedor". Texto: "Ao criar este pool, você define o preço inicial entre [Token A] e [Token B]. Atenção: se o preço estiver muito diferente do mercado, arbitradores corrigirão imediatamente e você pode perder parte do aporte. [Saiba mais ▾]". CTA ativo após rolar até o card.

Rede errada / não suportada: Banner no topo do fluxo: "Este pool não existe na rede atual ([Rede X]). Troque para [Rede Recomendada] ou escolha outro par." CTA bloqueado.

Carteira não conectada: CTA "Conectar carteira para continuar". Saldos dos tokens não exibidos nos campos. Modo de provisão e card de pool ainda carregam e ficam visíveis — o usuário pode explorar o fluxo antes de conectar (try-before-connect).

Token com risco detectado (scan inline): Badge ⚠ ao lado do nome do token no seletor. Ao selecionar: banner inline "Token não verificado — verifique o endereço antes de continuar. [Ver detalhes]". CTA ativo — não bloqueia, sinaliza.

5. Microcopy crítico

Label de campo par:

Token A: "Primeiro token"
Token B: "Segundo token"
Placeholder nos campos: "Buscar por nome ou colar endereço"

Instrução inline (acima dos campos de par): "Escolha os dois tokens para os quais você quer fornecer liquidez."

Cards de modo (microcopy completo):

Card Simples:

Título: "Simples — depositar e esquecer"
Subtítulo: "Deposite e receba taxas automaticamente. Sem ajustes necessários."
Chip: "Passiva"
Secondary: "Provisão clássica (V2)"
Badge: "Recomendado para iniciantes" (quando aplicável)

Card Concentrada:

Título: "Concentrada — mais retorno, mais atenção"
Subtítulo: "Defina uma faixa de preço. Retorno maior enquanto o preço estiver dentro dela."
Chip: "Gestão ativa"
Secondary: "Provisão com faixa (V3)"
Nota inline quando selecionado: "Quando o preço sair da sua faixa, você para de ganhar taxas até reajustar."

Card Programável:

Título: "Programável — controle total"
Subtítulo: "Configure regras personalizadas. Requer conhecimento técnico de hooks."
Chip: "Configuração técnica"
Secondary: "Provisão customizável (V4)"
Banner após seleção: "Modo avançado. Você pode começar com 'Simples' e migrar depois."

Card de saúde do pool:

Colapsado: "Ver detalhes do pool ▾"
Badge pool ativo: "Pool ativo"
Badge pool pouco ativo: "⚠ Pool pouco ativo"
Badge pool novo: "Novo pool — você define o preço"
Aviso pool inativo: "Este pool tem baixo volume recente. Você pode ganhar menos taxas e estar exposto a mais impermanent loss sem compensação de taxas."
Aviso pool novo: "Você será o primeiro provedor. Ao criar este pool, você define o preço inicial entre [Token A] e [Token B]. Se o preço definido diferir do mercado, arbitradores corrigirão imediatamente."

CTA dinâmico:

Disabled sem par: "Selecionar os tokens"
Disabled sem modo: "Escolher o modo de provisão"
Enabled: "Configurar minha posição"
Enabled sem carteira: "Conectar carteira para continuar"

Mensagens de validação:

Token A = Token B: "Selecione um token diferente de [Token A]."
Token não verificado: "Token não verificado — verifique o endereço antes de continuar."
Pool inativo ao avançar: "Este pool tem pouca atividade. Deseja continuar mesmo assim?" + botões "Voltar" (secundário) / "Continuar" (primário neutro, não verde)
Erro de rede ao carregar pool: "Não conseguimos verificar o estado deste pool. [Tentar de novo] ou [Continuar mesmo assim]."

6. Rastreabilidade obrigatória

🟢 Herdado

Token A pré-selecionado com nativo da rede ativa → default do caso 90% sem forçar. [uniswap-nova-posicao § Pontos isolados — Tela 1: ETH pré-selecionado como Token A]
Stepper de progresso com labels contextuais → contrato visual de progressão; sinaliza quantas etapas e o que cada uma exige. [uniswap-nova-posicao § 🟢 Stepper pedagógico e contextual]
Microcopy inline abaixo dos campos → sempre visível, evita tooltip hover-only. [uniswap-nova-posicao § 🟢 Microcopy pedagógica inline]
Try-before-connect → fluxo explorável sem carteira; usuário vê o produto antes de se comprometer. [uniswap-final § Padrão da Uniswap que NÃO se tornou fricção — try-before-connect]
URL parametrizada para par + modo → compartilhamento de setup; deep link de setups específicos. [uniswap-nova-posicao § Observações adicionais — URL como state machine]
Seção "Sugeridos" hierarquizada (recentes → trending rede → trending global) no seletor de token. [pancake-final § Pilar 6 — CTA dinâmico + Default contextual]
Badge de emissão visível no token (Canônico/Wrapped/Pegged) no seletor. [pancake-final § Pilar 3 — Risk signaling sistêmico] e [uniswap-final § Pilar 3 — Canonical mapping + risk signaling]

🔴 Corrige

Versão/protocolo como caixa-preta técnica sem pedagogia — a friction estrutural mais transversal de ambos os DEXes. Endereça com cards de modo em linguagem de benefício, não nomenclatura técnica. [uniswap-nova-posicao § 🔴 Estrutural — Versão como caixa-preta técnica] + [pancake-adicionar-liquidez § 🔴 Estrutural — Seleção de protocolo como caixa-preta técnica]
Ausência de estado do pool destino na janela de decisão de aporte — o card de saúde do pool aparece ANTES de o usuário avançar, não após. [uniswap-nova-posicao § 🔴 Estrutural — Ausência de estado do pool destino]
Léxico de protocolo como vocabulário primário de UI — labels de modo são verbos de intenção; nome técnico é secondary/tooltip. [pancake-final § Fricção 1 — Léxico de protocolo e infraestrutura] e [uniswap-final § Fricção 1 — Léxico de protocolo como UI]
CTA disabled silencioso sem comunicar o gap — CTA muda de label conforme o passo faltante. [pancake-final § Fricção 10 — CTA disabled silencioso]
Componente de filtro de pool: vocabulário intraduzível — labels de modo por consequência financeira, não mecânica técnica (CLAMM/LBAMM não aparecem nesta tela). [pancake-adicionar-liquidez § 🔴 Estrutural — Componente de filtro de pool]
i18n parcial — inglês técnico dentro de UI PT-BR — toda microcopy em PT-BR; V2/V3/V4 como secondary label discreto. [pancake-final § Fricção 2 — i18n parcial]

🟡 Captura

Entrada por intenção: protocolo recomendado por par, não escolhido como pré-requisito — o usuário declara o par primeiro; o sistema sugere o modo com badge contextual. [pancake-adicionar-liquidez § 🟡 Oportunidade 1 — Entrada por intenção] + Path B: inverter o fluxo.
Pedagogia de versão como decisão arquitetural primária — 3 cards de trade-off como primeira decisão de modo, com default sugerido = "Simples" para iniciante. [uniswap-nova-posicao § 🟡 Oportunidade 1 — Pedagogia de versão] + Path B estratégico.
Pré-visualização do pool destino antes do depósito — card de saúde do pool na etapa de configuração de par, não após commit. [uniswap-nova-posicao § 🟡 Oportunidade 2 — Card de pré-visualização] + [uniswap-final § Pilar 5 — Pré-visualização rica antes de input]
Validação par↔protocolo inline antes do aporte — alerta contextual para combinações improváveis (par exótico sem liquidez em modo concentrado). [pancake-adicionar-liquidez § 🟡 Oportunidade 3 — Validação par↔protocolo inline]
Risk signaling sistêmico no seletor de token — badges de emissão + tokens não verificados sinalizados antes do clique. [pancake-final § Pilar 3] + [uniswap-final § Pilar 3]

⚪ Novo

Heurística de recomendação de modo por par: o sistema inferir "Simples" vs "Concentrada" vs "Programável" com base no tipo de par não tem origem direta nos consolidados (que descrevem a oportunidade mas não especificam a heurística). Justificativa: sem essa heurística, o badge "Recomendado" é arbitrário e perde valor. Evidência a coletar: taxa de conversão por modo recomendado vs modo escolhido; taxa de abandono após recomendação divergente. Custo se a heurística errar: recomendação contraproducente piora a experiência vs ausência de recomendação. Mitigação: critérios conservadores (Simples como default), threshold de confiança mínimo para ativar o badge (ex: par com > $100K TVL no modo recomendado).
Scroll sentinel para pool novo: exigir que o usuário role até o card de aviso antes de habilitar o CTA. Justificativa: o aviso de "você define o preço inicial" é informação crítica de risco — não é Tier 1 (type-to-confirm) porque o usuário não está confirmando nada ainda; mas exigir scroll garante que o aviso foi visto, não apenas renderizado acima do fold. Custo: atrito leve para usuários que já conhecem a mecânica. Evidência a coletar: % de usuários que abriram o card expandido manualmente vs automaticamente.

7. Trade-offs e segunda ordem

Heurística de recomendação de modo: a regra de "par estável → Simples, par volátil → Concentrada" exige manutenção contínua de um mapeamento par↔tipo e thresholds de TVL/Volume que determinam quando o badge aparece. Se a heurística estiver errada, o badge "Recomendado" cria confiança falsa — pior que ausência de recomendação. Custo de engenharia: médio. Custo de manutenção: recorrente por release.

Cards de modo em linguagem de benefício: labels mais longos que os chips técnicos concorrentes (V2/V3) exigem testes de layout em mobile < 375px. Nomes mais longos aumentam surface area de i18n — tradução para ES/EN dos labels de modo precisa preservar o caráter pedagógico, não só traduzir literalmente.

Card de saúde do pool na Tela 01: adiciona uma consulta de API extra antes de avançar, aumentando latência percebida na etapa de configuração do par. Mitigação: skeleton imediato + timeout de 5s com fallback de "continuar mesmo assim". Risco de falso positivo: pool marcado como "inativo" por dados desatualizados de indexador — adiciona atrito desnecessário. Mitigação: usar janela de 24h, não ponto no tempo.

Try-before-connect: saldos não disponíveis sem carteira; card de saúde do pool carrega mas saldos ficam em branco. UX coerente mas pode gerar confusão em mobile onde o usuário espera que o "Conectar" apareça mais cedo. Prioridade do Pilar 7 (Mobile-first) e Pilar 6 (Default contextual) resolvem: CTA muda de label para "Conectar carteira para continuar" quando o usuário tenta avançar.

Modo "Programável" no fluxo padrão: expor V4 (hooks, configuração técnica) para usuário que pode ser iniciante tem custo de cognitive load. Mitigação: chip "Configuração técnica" e o banner de "modo avançado" sinalizam claramente que é opt-in para avançado. Não é bloqueio porque A8 (inverter sem motivo padrão herdável) se aplica: remover completamente V4 da lista exigiria justificativa de que o iniciante não pode acessá-lo nem via erro.

Pools — Tela 2 — Detalhe do pool ("Avaliar antes de aportar")

Função da tela

Tela de avaliação de um pool específico: o usuário (foco em iniciante, com intermediário como segundo perfil) precisa responder "este pool é bom para eu entrar?" antes de comprometer capital. Resolve a lacuna central do fluxo de pools dos concorrentes — onde o detalhe existe mas entrega dados sem mediação, e o contexto de saúde some exatamente quando o widget de ação abre.

Componentes / elementos

Estrutural (define o paradigma da tela)

Header de identidade sticky
- Par em destaque: ETH/USDC (fonte primária, sempre visível em scroll).
- Versão e fee como secondary label inline: V3 · 0,05%.
- Breadcrumb colapsado em mobile: Ganhar rendimento › ETH/USDC — tap no breadcrumb volta para pools-01 preservando filtros.
- Se o pool tiver badge de risk (token não verificado, APR extremo): badge ⚠ vermelho aparece no header sticky — não só na seção de saúde.
Chip-strip de saúde (componente central, mobile-first)
- Linha horizontal fixa acima do chart: Rend. est. (7d) 12,4% · TVL R$ 135 M · Vol. 24h ↑1,3%
- Em mobile: substitui a sidebar desktop que fica atrás de dois scrolls (fricção estrutural do Uniswap visualizar-pool). Permanece ancorado enquanto o chart sai do viewport.
- Cada chip é tocável → abre bottom sheet com contexto narrativo do KPI:
  - Tap em Rend. est. → sheet com tooltip pedagógico completo sobre IL + janela de cálculo.
  - Tap em TVL → sheet com mini-chart 7d de TVL + caption narrativa.
  - Tap em Vol. → sheet com mini-chart 7d de volume + caption narrativa.
- Cor do strip: neutro (cinza) para pool saudável, âmbar para pool com sinal de atenção, vermelho para pool morta (Vol/TVL < 0,01 por ≥ 7 dias).
Chart de atividade
- Default: Volume (não Preço) — quem está na detail view pensa em saúde de infraestrutura, não em trajetória de token.
- Label da área: Atividade do pool (não "Volume", não "Price").
- Presets de período: 24h | 7d | 30d — chips horizontais, tap-and-stick em mobile.
- Caption automática abaixo do chart (gerada por regra com dados já carregados):
  - Atividade normal: "Volume distribuído ao longo do dia sem pico isolado."
  - Concentrada: "Atividade concentrada em 1 transação às 06h (67% do volume)."
  - Baixa: "Sem transações nas últimas 24h."
  - Spike isolado: "Pico de volume às 03h. 1 transação representou 89% do total do dia."
- Máximo 5 templates conservadores — caption errada em caso extremo é pior que silêncio.
Card de saúde do pool (sidebar em desktop, abaixo do chart em mobile)
- Rendimento estimado (7d, sem IL) ⓘ — com tooltip pedagógico idêntico ao de pools-01 (consistência de vocabulário entre telas).
- TVL com variação 24h em delta colorido (↑ verde / ↓ vermelho).
- Volume 24h com variação 24h.
- Tarifas coletadas (24h) — em R$ quando locale BR; sem mistura de separadores (R$ 1.234,56, nunca $1,23K).
- Composição do par: barra de proporção horizontal full-width com labels percentuais inline — 52% ETH / 48% USDC. Resolve a perda da barra de proporção do desktop Uniswap no mobile.
  - Se um token > 85% → badge âmbar sobreposto: "Pool desbalanceada. Aporte pode ter impacto de preço elevado."
- Caption narrativa de APR quando APR < 0,1% e Vol/TVL < 0,01 (pool morta com número gigante e silêncio explicativo):
  - "Pool com volume baixo. As taxas coletadas nas últimas 24h são insuficientes para gerar rendimento significativo."
  - Derruba a fricção "APR 0,00% mudo em fonte gigante" do Uniswap.
- Risk badges do pool: reaparece o mesmo sistema de badges de pools-01, agora com contexto narrativo expandido:
  - ⚠ amarelo — Vol/TVL > 3,0: "Volume excepcionalmente alto pode indicar negociação artificial ou incentivo temporário."
  - ⚠ amarelo — APR > 100%: "Rendimentos acima de 100% raramente se sustentam. Veja a janela de cálculo."
  - ⚠ vermelho — token não verificado: "Pelo menos um token deste pool não passou nos critérios de verificação."
Tabela de transações
- Desktop — colunas: Tipo (↓/↑ colorido) · USD · Qtd. Token A · Qtd. Token B · Carteira · Horário.
  - Coluna Tipo = ícone colorido sem texto de token — par implícito no header sticky, elimina truncamento "Vender WIS…".
  - Carteira com badge via roteador quando contrato = roteador/agregador canônico (1inch, Universal Router, etc.).
- Mobile — 3 colunas visíveis: Tipo · USD · Horário + chevron › na borda direita.
  - Tap no chevron abre bottom sheet (60% viewport) com card detalhado: Tipo, USD, Qtd. de cada token, Carteira + badge, link explorer.
- Caption acima da tabela: "X transações em 24h · Y% do volume em 1 trade às 05h."
- Paginação simples: "Carregar mais" — sem scroll infinito mudo.
CTAs principais (sticky bar em mobile, sidebar em desktop)
- "Adicionar liquidez" — primário (cor de destaque, não verde CTA-padrão quando o pool tiver badge de risco — mantém destaque mas sem cor de "aprovação" para pool problemática).
- "Fazer troca" — secundário (outline). Par da pool é herdado: abre swap com ETH e USDC pré-selecionados, não swap vazio.
- Mobile: dois botões em coluna full-width na sticky bar — resolve o truncamento garantido de "Adicionar liqu…" quando dois botões dividem uma barra horizontal.
- Quando pool tem sinal de atenção: aviso inline abaixo do CTA primário — "Pool com baixa atividade — verifique antes de aportar." (não bloqueia o CTA — soberania do usuário preservada).
Section de contratos (colapsada por default)
- Eyebrow POOL ou TOKEN antes de cada endereço (soluciona o truncamento de nomes longos no mobile — ex.: "P…", "Wise…", "Wrapp…" viram contexto semântico sem depender do nome completo).
- Copy + link para explorer externo (rotulado, não endereço cru).

Cosmético (polish, vai depois do estrutural)

Seletor de período do chart — chips 24h | 7d | 30d, estado ativo visível por underline ou fundo.
Timestamp de dados — rodapé discreto: "Dados em 11:28 · atualiza a cada 30s." — todos os KPIs da página derivam do mesmo snapshot; divergência intra-tela é garantia arquitetural, não coincidência.
Link "Denunciar pool" — extremo inferior, texto discreto, não feature primária.

Regras de negócio

Herança de contexto obrigatória: quando o usuário chega via "Ver detalhes" em pools-01, par e versão já estão definidos. CTA "Fazer troca" herda o par — não abre swap com campos vazios.
Chip-strip persiste em mobile durante todo o scroll da página — não some quando o chart sai da viewport. Dado crítico para a decisão de aporte não pode ser escondido pelo conteúdo subsequente.
Caption narrativa de APR é ativada por bucket de situação: APR < 0,1% AND Vol/TVL < 0,01 → caption de pool morta; APR > 100% → caption de APR extremo com janela de cálculo. Fora dessas faixas → sem caption (silêncio é neutro; texto errado é pior que silêncio).
Badge de pool desbalanceada: threshold em 85% de um lado. Threshold revelado no tooltip — critério explícito, não opaco.
Timestamp unificado: todos os KPIs (TVL, Vol, Tarifas, Rendimento) derivam do mesmo snapshot do backend. Divergência intra-tela é bug, não aceitável — timestamp discreto no rodapé torna isso auditável pelo usuário.
Risk badges: mesmos critérios de pools-01 (Vol/TVL > 3,0 → ⚠ amarelo; APR > 100% → ⚠ amarelo; token não verificado → ⚠ vermelho). Na detail view, o badge expande para contexto narrativo mais longo (não só o tooltip de 1 linha da lista).
CTA "Adicionar liquidez": leva para pools-03 com par e protocolo mais usado para o par já pré-definidos. Se o usuário chegou via uma instância específica de pool (ex: ETH/USDC V3 0,05%), a seleção é mais granular.
Pool morta (Vol/TVL < 0,01 por ≥ 7 dias): CTA "Adicionar liquidez" permanece acessível com aviso inline. Não bloquear — usuário avançado pode ter razão para aportar.

Estados não-triviais

Estado	Comportamento
Loading inicial	Skeleton com label: "Carregando dados do pool ETH/USDC…" — skeleton cobre chip-strip, chart e card de saúde. Nunca skeleton mudo.
Erro de RPC / subgraph	Banner não bloqueante no topo: "Dados desatualizados há X minutos. Tentando reconectar…" + CTA Tentar agora. Tabela de transações mostra última versão em cache com timestamp visível.
Pool morta (Vol/TVL < 0,01 por ≥ 7d)	Chip-strip em âmbar. Caption do chart: "Sem transações nas últimas 24h." Caption de APR: "Pool com volume baixo. Taxas insuficientes para gerar rendimento significativo." CTA com aviso inline — não bloqueante.
Pool com token não verificado	Badge ⚠ vermelho no header sticky + na section de contratos + tooltip expandido. CTA com aviso inline: "Pelo menos um token não passou na verificação — revise antes de aportar." Não bloqueante.
Pool desbalanceada (um token > 85%)	Badge âmbar na barra de proporção + tooltip pedagógico sobre impacto de preço.
Sem wallet conectada	Toda a visualização disponível. Ao clicar em "Adicionar liquidez" → fluxo de conexão de carteira (não bloqueia visualização prévia). "Fazer troca" também acessível.
Rede ativa ≠ rede do pool	Banner: "Você está na rede [X]. Este pool existe na rede [Y]. Mude para continuar." + CTA de troca de rede inline. CTAs principais desabilitados com texto de contexto, não botões cinzas mudos.
Parcial multi-chain (RPC de rede do pool falhando)	Banner discreto: "Não foi possível carregar dados desta rede. Mostrando última versão disponível." — chart e tabela exibem dados em cache com timestamp.
Retorno do fluxo de adição (back-navigation de pools-03)	Página recarrega dados — sem estado especial de "sucesso" nesta tela; sucesso fica em pools-03.

Microcopy crítico (PT-BR)

Elemento	Texto
Header	ETH/USDC · V3 · 0,05%
Breadcrumb	Ganhar rendimento › ETH/USDC
Chip-strip	Rend. est. (7d) 12,4% · TVL R$ 135 M · Vol. 24h ↑1,3%
Label do chart	Atividade do pool
Presets de período	24h \| 7d \| 30d
Caption — atividade normal	Volume distribuído ao longo do dia sem pico isolado.
Caption — concentrada	Atividade concentrada em 1 transação às 06h (67% do volume).
Caption — pool sem volume	Sem transações nas últimas 24h.
Caption — APR pool morta	Pool com volume baixo. As taxas coletadas nas últimas 24h são insuficientes para gerar rendimento significativo.
Caption — transações	9 transações em 24h · 67% do volume em 1 trade às 05h.
Label de rendimento	Rendimento estimado (7d, sem IL) ⓘ
Tooltip de rendimento	Cálculo baseado nas taxas observadas nos últimos 7 dias. Não inclui perda impermanente (IL) — o resultado real depende da variação de preço dos dois tokens.
Label tarifas	Tarifas coletadas (24h)
Composição do par	52% ETH / 48% USDC
Badge pool desbalanceada	Pool desbalanceada. Aporte pode ter impacto de preço elevado.
CTA primário	Adicionar liquidez
Aviso inline CTA — pool morta	Pool com baixa atividade — verifique antes de aportar.
Aviso inline CTA — token não verificado	Pelo menos um token não passou na verificação — revise antes de aportar.
CTA secundário	Fazer troca
Badge ⚠ Vol/TVL alto (expandido)	Volume excepcionalmente alto pode indicar negociação artificial ou incentivo temporário. Verifique a trajetória antes de aportar.
Badge ⚠ APR extremo (expandido)	Rendimentos acima de 100% raramente se sustentam. Veja a janela de cálculo antes de aportar.
Badge ⚠ token não verificado (header)	⚠ Token não verificado
Eyebrow contrato	POOL
Eyebrow token	TOKEN
Timestamp	Dados em 11:28 · atualiza a cada 30s
Loading	Carregando dados do pool ETH/USDC…
Erro de dados	Dados desatualizados há X minutos. Tentando reconectar…
CTA retry	Tentar agora
Rede errada	Você está na rede [X]. Este pool existe na rede [Y]. Mude a rede para continuar.
CTA rede errada	Mudar para [Y]
Sem wallet + CTA ação	Conectar carteira para adicionar liquidez

Rastreabilidade obrigatória

🟢 Herdado

Herança de contexto no widget de ação: par pré-preenchido em "Fazer troca" vindo do pool em contexto; breadcrumb Ganhar rendimento › ETH/USDC mantido em mobile. Fonte: [uniswap visualizar-pool § Insight — Contexto herdado na ação]
Chart default = Volume: quem está na detail view pensa em saúde de infraestrutura, não em trajetória de token. Fonte: [uniswap visualizar-pool § Insight — Contexto herdado na ação — chart por Volume]
Presets chips de período (24h/7d/30d): elimina cálculo cognitivo em toda decisão com âncora temporal. Fonte: [uniswap visualizar-pool § Insight — Presets chips em qualquer decisão financeira]
Tap-and-stick no chart em mobile. Fonte: [pancake-final § Pilar 5 — Mobile-first interaction]
Dados on-chain inline (tabela de transações sem desvio para explorer externo). Fonte: [uniswap visualizar-pool § Insight — Dados on-chain inline]
Sticky de identidade + CTAs em mobile: header compacto sticky + CTAs na sticky bar inferior. Fonte: [uniswap visualizar-pool § Insight — Sticky de identidade + CTAs em mobile]
Risk badges herdados da lista com critério consistente: mesmos thresholds de pools-01. Fonte: [uniswap pools § Oportunidade — Verificação por token em pool] + [pancake-final § Pilar 6]
Sinalização de risco in-place sem friction transacional: badge e aviso inline no CTA, nunca popup no final. Fonte: [uniswap visualizar-pool § Insight — Sinalização de risco in-place]

🔴 Corrige

APR 0,00% mudo em fonte gigante → Caption narrativa contextual gerada por bucket de situação (pool morta, pool ativa, APR extremo). Fonte: [uniswap visualizar-pool § Fricção estrutural — APR 0,00% mudo]
Desacoplamento widget↔contexto no ato de decidir → Chip-strip de saúde permanece visível em mobile durante o scroll; sidebar permanente em desktop; aviso inline no CTA quando pool problemática. Fonte: [uniswap visualizar-pool § Fricção estrutural — Desacoplamento widget↔contexto]
Paridade informacional desktop↔mobile quebrada → Chip-strip de saúde acima do chart em mobile substitui a sidebar desktop; barra de proporção horizontal preservada em mobile. Fonte: [uniswap visualizar-pool § Fricção estrutural — Paridade informacional desktop↔mobile quebrada]
Truncamentos PT-BR sistêmicos → Dois CTAs em coluna full-width na sticky bar mobile; eyebrow POOL/TOKEN em contratos substitui labels de nome longo. Fonte: [uniswap visualizar-pool § Fricção estrutural — Truncamentos PT-BR sistêmicos]
Coluna Tipo truncada na tabela → Ícone colorido ↓/↑ sem texto; par implícito no header sticky. Fonte: [uniswap visualizar-pool § Cosmético-estrutural — Coluna Tipo truncada]
Métricas vivas sem âncora de snapshot → Timestamp unificado no rodapé; todos os KPIs derivam do mesmo snapshot — divergência intra-tela é bug, não aceitável. Fonte: [uniswap visualizar-pool § Fricção estrutural — Métricas vivas sem âncora de snapshot]
Fricção #2 — i18n parcial → Todos os KPIs, labels e tooltips desta tela em PT-BR; formato numérico locale BR (R$ 1.234,56, nunca mistura). Fonte: [pancake-final § Fricção 2 — i18n parcial]

🟡 Captura

Chip-strip de saúde persistente em mobile — APR, TVL e Vol nunca saem do viewport durante decisão de aporte. Pilar: [pancake-final § Pilar 5 — Mobile-first interaction] + [uniswap visualizar-pool § Oportunidade — Contexto persistente no ato de operar]. Hipótese: usuário não decide adicionar liquidez sem ver os 3 KPIs — chip-strip elimina o risco de "aportar em pool morta achando que é normal".
Caption automática de chart e transações — narrativa de dados em 3 níveis (chart, transações, KPI) com templates por situação. Pilar: [pancake-final § Pilar 4 — Educação contextual] + [uniswap visualizar-pool § Oportunidade — Narrativa automática dos dados]. Hipótese: uma frase muda o tipo de pergunta que o usuário faz antes de aportar.
Composição do par como barra de proporção em ambos os breakpoints — visual de desequilíbrio acessível em mobile sem cálculo mental. Captura lacuna: [uniswap visualizar-pool § Fricção — Paridade informacional desktop↔mobile — barra descartada em mobile]. Hipótese: pool desbalanceada identificada em < 3s vs identificação impossível em mobile hoje.
Row-expand na tabela de transações em mobile — paridade informacional completa com desktop sem sair do produto. [uniswap visualizar-pool § Oportunidade — Tabela mobile expansível por linha]. Hipótese: auditoria de fluxo de caixa do pool disponível em mobile, eliminando desvio para Etherscan.
Risk signaling sistêmico na detail view — badges herdados da lista entram na tela de detalhe com contexto narrativo expandido. Pilar: [pancake-final § Pilar 6 — Risk signaling sistêmico]. Hipótese: usuário que chega ao detalhe com intenção de aportar vê o mesmo sinal que bloqueou o clique na lista — consistência de signal trail.

⚪ Novo

Badge de pool desbalanceada (threshold: um token > 85% da composição) na barra de proporção. Não aparece nos relatórios como feature de visualização de pool. Justificativa: pools muito desbalanceadas têm impacto de preço elevado para quem entra com o par 50/50; o sinal é calculável com dados já disponíveis (composição). Risco: threshold de 85% é heurística — calibragem errada vira ruído. Evidência futura a coletar: impacto de preço médio em pools ≥ 85% para aportes de tamanho típico do target; ajustar threshold com dados.

Trade-offs e segunda ordem

Caption automática exige 4–5 templates conservadores por nível + i18n. Caption errada em casos extremos (ex.: pool com volume legítimo altíssimo classificada como "wash trading") é pior que silêncio — limitar templates a situações inequívocas.
Chip-strip de saúde em mobile adiciona ~36 px no topo acima do chart; threshold de "pool morta" precisa ser exposto como critério — calibragem errada gera falsos positivos de alerta.
Row-expand na tabela mobile exige dois toques para info que desktop entrega em um olhar — aceitável dado que elimina abandono de produto para Etherscan. Risco baixo.
Badge de pool desbalanceada adiciona estado de componente à barra de proporção — mais sincronização de estado; threshold de 85% é opinião com pretensão de objetividade, aceitar revelando o critério.
Timestamp unificado requer snapshot coerente no backend — sem isso, o timestamp vira decoração de dados inconsistentes. Custo de observabilidade real; deve ser decisão arquitetural antes da implementação desta tela.
Barra de proporção em mobile em proporções extremas (1%/99%) renderiza mal em largura restrita — mitigação: largura mínima de segmento menor = 4px para manter legibilidade, com label percentual sempre visível mesmo em segmento estreito.
Badge ⚠ no header sticky infla levemente o espaço vertical do header em mobile — mitigação: badge compacto (12px), sem texto no header; tooltip aparece ao tocar.

Conflitos de pilar resolvidos

Pilar 4 (educação contextual: caption de APR explicando pool morta) vs Pilar 7 (curadoria opinionada: não inventar julgamento editorial sobre o pool). Resolvido por templates conservadores que descrevem fato observado ("taxas insuficientes"), não julgamento de valor ("este pool é ruim"). A caption não diz "não aposte aqui" — descreve o estado observado e deixa a decisão com o usuário.
Pilar 3 (defesa em camadas: alertar sobre pool com sinal de risco) vs Pilar 7 (curadoria: não bloquear soberania do usuário). Resolvido mantendo CTA "Adicionar liquidez" sempre disponível, com aviso inline contextual. O alerta está no caminho, não bloqueia o caminho — hierarquia de pilar 3 < 7 aqui porque soberania do usuário vence paternalismo (A3 — solução pior que o problema se bloquearmos).

Pools — Tela 3 — Adicionar liquidez: par + protocolo recomendado

Função da tela

Primeira tela do fluxo de adição de liquidez: o usuário (foco em iniciante) declara o par e recebe uma recomendação de protocolo com justificativa baseada em dados — substituindo a escolha técnica neutra ("V2/V3/Infinity/StableSwap?") por orientação contextual com critério explícito. Resolve "em qual protocolo devo aportar para este par?" antes de qualquer decisão de valor ou range.

Componentes / elementos

Estrutural (define o paradigma da tela)

Cabeçalho da tela
- Título: "Adicionar liquidez" (verbo de intenção, não "Pools" ou "Provide Liquidity").
- Sub-título: "Escolha o par e o protocolo para o seu aporte."
- Se o usuário veio de pools-02 com par pré-definido → sub-título contextual: "Configurando aporte em ETH/USDC."
Seletor de par (estrutural, pré-preenchido se vindo de pools-02)
- Dois token selectors lado a lado, com busca integrada (mesmo comportamento de busca do swap — consistência de componente).
- Estado vazio (entrada direta sem contexto de pool): chips qualitativos de atalho abaixo dos seletores: Stablecoins | Blue-chip | Recentes. Chips disparam busca filtrada — atalho para os casos mais comuns do iniciante sem exigir digitação.
- Estado pré-preenchido (vindo de pools-02): par visível, com CTA secundário discreto "Trocar par ▾" para ajuste. Não há botão de "resetar" em destaque — o par chegou com contexto; mudar é exceção.
- Assim que o par é selecionado, o card de protocolo recomendado é acionado.
Card de protocolo recomendado (componente central desta tela)
- Aparece após o par ser selecionado — não antes. Não exige que o usuário conheça os protocolos antes de saber o que está negociando.
- Conteúdo do card:
  - Linha 1: "Para ETH/USDC, recomendamos V3" — par + protocolo em linguagem declarativa.
  - Linha 2 (dados): "72% do volume ativo está concentrado aqui. Fee tier: 0,05%." — justificativa em dado observado, não editorial.
  - Linha 3 (consequência): descrição do protocolo em verbo de consequência — "Concentrado num range: maior eficiência de capital, mas exige definição de faixa de preço e rebalanceamento eventual."
  - Badge lateral: "Mais popular para este par" — critério baseado em volume observado, não curadoria editorial.
- CTA primário do card: "Usar recomendação" — confirma par + protocolo e avança para configuração de range e valor.
- Link secundário abaixo: "Ver outras opções ▾" — expande o seletor de protocolo manual sem sair da tela.

Seletor de protocolo manual (colapsado por default, expande ao clicar "Ver outras opções ▾")

Cards verticais com label de consequência como nome primário e nome técnico como sub-label:

Card	Nome primário	Descrição	Sub-label
V2	Simples e passivo	Deposita e esquece. Sem gestão de faixa de preço. Rendimento distribuído uniformemente.	`V2`
V3	Concentrado num range	Maior eficiência de capital. Exige definição de faixa de preço e eventual rebalanceamento.	`V3`
StableSwap	Pares correlacionados	Otimizado para stablecoins e pares com preço próximo. Não usar para pares voláteis.	`StableSwap`
Infinity	Customizável (avançado)	Lógica programável de LP. Para usuários com experiência em AMM.	`Infinity`

Card da recomendação ativa mantém badge "Mais popular para este par" mesmo com o seletor expandido.
Tap em qualquer card o marca como selecionado; o card de recomendação passa ao estado "selecionado" visualmente distinto do "apenas exibido".
Seleção manual não exibe aviso adicional de "saindo da recomendação" — não paternalismo. A. 3: solução pior que o problema.

Warning de combinação par×protocolo imprópria (aparece inline, não em modal separado)
- Acionado quando a combinação é objetivamente imprópria:
  - Par com volatilidade histórica alta + StableSwap selecionado.
  - Par de stablecoins (correlação alta) + V3 com fee tier > 0,3% selecionada.
- Aparece entre o card de protocolo e o rodapé, sem bloquear a tela:
  - "BNB e CAKE não são ativos correlacionados. StableSwap é otimizado para pares como USDC/USDT. Continuar com V3?"
- CTAs do warning: "Usar V3 (recomendado)" (primário, cor normal) | "Continuar assim mesmo" (secundário, texto simples, sem estilo destrutivo — é escolha válida do avançado, não ação destrutiva Tier 1).
- Warning não bloqueia CTA de avançar — usuário pode confirmar e prosseguir. Soberania preservada.
Resumo fixo no rodapé (sticky em mobile, inline em desktop)
- Par + Protocolo + Fee tier: ETH/USDC · V3 · 0,05%
- CTA: "Continuar →" — avança para a próxima tela do fluxo (range e valor de aporte, fora do escopo de pools-03).
- Quando par ainda não selecionado: CTA desabilitado com label contextual — "Selecione um par para continuar" (não botão cinza mudo).
- Quando par selecionado mas aguardando recomendação: CTA desabilitado — "Avaliando protocolo…"
- Quando sem wallet: CTA muda para "Conectar carteira para continuar".

Cosmético (polish, vai depois do estrutural)

Link "Como funciona este protocolo?" discreto abaixo de cada card de protocolo — abre painel lateral (ou bottom sheet em mobile) com explicação pedagógica de 3–4 linhas. Um painel por protocolo, não um glossário genérico.
Chip "Mais popular para este par" no card recomendado — visual, não texto — ícone de barra de atividade ou badge compacto.

Regras de negócio

Heurística de recomendação de protocolo por par

A heurística é baseada em dados observados (volume por protocolo + fee tier para o par) — não editorial:

Tipo de par	Protocolo recomendado	Fee tier
Estável × estável (USDC/USDT, USDC/DAI, USDT/BUSD)	StableSwap ou V3 0,01%	0,01%
Blue-chip + stable (ETH/USDC, BNB/USDT, BTC/USDC)	V3, fee tier com maior volume observado	Geralmente 0,05%
Blue-chip + blue-chip (ETH/BTC, ETH/BNB)	V3	0,3%
Par volátil sem histórico suficiente	V2	0,3%
Par desconhecido (< 30d de histórico)	V2 — "ponto de partida seguro"	0,3%

Justificativa da recomendação é sempre baseada em dado observado ("72% do volume ativo está aqui") — nunca editorial genérico ("recomendamos porque é melhor").
Fee tier pré-selecionada = fee tier com maior volume observado para o par nos últimos 7d. Usuário pode mudar via "Mais opções de fee ▾" (não é decisão de primeiro nível para iniciante).
Se API de dados falhar: fallback automático para V2 como recomendação segura — "Não foi possível carregar a recomendação. Sugerimos V2 como ponto de partida seguro." Seletor manual expande automaticamente no fallback.

Herança de contexto de pools-02

Par já definido: seletor pré-preenchido; card de recomendação carrega sem interação adicional.
Protocolo já definido (usuário clicou em instância específica em pools-01 ou pools-02, ex: ETH/USDC V3 0,05%): card de protocolo aparece no estado "pré-confirmado" — usuário pode mudar, mas o default é a instância de origem.
Sem contexto (entrada direta): seletor de par vazio, card de recomendação ausente até seleção.

Warning de incompatibilidade par×protocolo

Regras de disparo (OR — basta 1):

Par com volatilidade histórica > 20% (30d) + StableSwap selecionado.
Par com correlação histórica > 0,9 (30d) + V3 com fee tier > 0,3%.

Warning é informativo, não bloqueante. CTA "Continuar assim mesmo" permanece disponível. Critério de volatilidade e correlação é revelado no link "Como funciona isso?" abaixo do warning.

Fee tier

Primeiro nível: fee tier com maior volume observado, pré-selecionada invisível — aparece no resumo do rodapé.
Ajuste: link "Mudar fee tier ▾" no resumo do rodapé, expande chips com as opções disponíveis para o par. Não é decisão de primeiro nível; iniciante não precisa saber o que é fee tier para avançar.

Estados não-triviais

Estado	Comportamento
Vazio — entrada direta	Seletor de par vazio + chips qualitativos (Stablecoins / Blue-chip / Recentes). Card de protocolo ausente. CTA com label "Selecione um par para continuar", desabilitado.
Par selecionado — aguardando recomendação	Skeleton no card de protocolo: "Avaliando o melhor protocolo para ETH/USDC…" CTA desabilitado: "Avaliando protocolo…"
Par sem histórico suficiente (< 30d ou volume < threshold)	Card de protocolo em estado informativo: "Não temos dados suficientes para este par. Sugerimos V2 como ponto de partida seguro." Seletor manual disponível.
Combinação par×protocolo imprópria	Warning inline entre card e rodapé (ver regras de negócio). Não modal.
Sem wallet conectada	Formulário disponível para exploração (usuário pode ver recomendação e entender antes de conectar). CTA vira "Conectar carteira para continuar".
Rede incompatível (protocolo selecionado não disponível na rede ativa)	Warning inline: "V3 não está disponível em [rede atual]. Está disponível em: [lista de redes]. Mude a rede para continuar." CTA desabilitado com contexto.
Erro de heurística (API de recomendação falhou)	Card de protocolo em estado de fallback: "Não foi possível carregar a recomendação agora. Escolha manualmente:" → seletor manual expande automaticamente.
Pré-preenchido — vindo de pools-02	Par visível, card de recomendação em estado "pré-confirmado" (protocolo já marcado). CTA ativo: "Continuar →" com resumo visível no rodapé.
Sucesso	Usuário confirma par + protocolo → avança para tela de configuração de range e valor (pools-04, fora do escopo deste arquivo).

Microcopy crítico (PT-BR)

Elemento	Texto
Título da tela	Adicionar liquidez
Sub-título default	Escolha o par e o protocolo para o seu aporte.
Sub-título pré-preenchido	Configurando aporte em ETH/USDC.
Placeholder seletor de token	Selecionar token
Chips de atalho (estado vazio)	Stablecoins \| Blue-chip \| Recentes
CTA trocar par	Trocar par ▾
Card recomendado — declaração	Para ETH/USDC, recomendamos V3
Card recomendado — dados	72% do volume ativo está concentrado aqui. Fee tier: 0,05%.
Card recomendado — consequência	Concentrado num range: maior eficiência de capital, mas exige definição de faixa de preço e rebalanceamento eventual.
Badge recomendado	Mais popular para este par
CTA usar recomendação	Usar recomendação
Link opções manuais	Ver outras opções ▾
Card V2 — nome	Simples e passivo
Card V2 — descrição	Deposita e esquece. Sem gestão de faixa de preço. Rendimento distribuído uniformemente.
Card V2 — sub-label	V2
Card V3 — nome	Concentrado num range
Card V3 — descrição	Maior eficiência de capital. Exige escolha de faixa de preço e eventual rebalanceamento.
Card V3 — sub-label	V3
Card StableSwap — nome	Pares correlacionados
Card StableSwap — descrição	Otimizado para stablecoins e pares com preço próximo. Não usar para pares voláteis.
Card StableSwap — sub-label	StableSwap
Card Infinity — nome	Customizável (avançado)
Card Infinity — descrição	Lógica programável de LP. Para usuários com experiência em AMM.
Card Infinity — sub-label	Infinity
Warning par×protocolo	BNB e CAKE não são ativos correlacionados. StableSwap é otimizado para pares como USDC/USDT. Continuar com V3?
CTA warning — aceitar	Usar V3 (recomendado)
CTA warning — ignorar	Continuar assim mesmo
Par sem histórico	Não temos dados suficientes para este par. Sugerimos V2 como ponto de partida seguro.
Erro de heurística	Não foi possível carregar a recomendação agora. Escolha manualmente:
Loading recomendação	Avaliando o melhor protocolo para ETH/USDC…
CTA desabilitado — sem par	Selecione um par para continuar
CTA desabilitado — aguardando	Avaliando protocolo…
Sem wallet	Conectar carteira para continuar
Rede incompatível	V3 não está disponível em [rede]. Disponível em: [lista]. Mude a rede para continuar.
Resumo rodapé	ETH/USDC · V3 · 0,05%
CTA principal	Continuar →
Link fee tier	Mudar fee tier ▾
Link pedagógico por protocolo	Como funciona este protocolo?

Rastreabilidade obrigatória

🟢 Herdado

Herança de contexto: par (e protocolo quando disponível) pré-preenchido quando vindo de pools-02. Fonte: [uniswap visualizar-pool § Insight — Contexto herdado na ação]
Formulário adapta-se ao protocolo: campos que não existem para o protocolo selecionado somem. Fonte: [pancake adicionar-liquidez § Insight — Adaptação honesta do formulário ao protocolo] — Kotai herda o princípio e aplica na ausência de campos irrelevantes (fee tier, por exemplo, soma em V2).
CTA desabilitado com label contextual: botão nunca fica cinza mudo — descreve o que está faltando ("Selecione um par para continuar"). Fonte: [uniswap-final § Insight — Estados como instrução acionável] + [pancake-final § Insight — Transparência proativa antes do CTA]
Try-before-connect: formulário disponível para exploração sem wallet conectada; CTA muda para conexão apenas ao tentar avançar. Fonte: [uniswap-final § Insight — Ação imediata sem commit nem onboarding]
Warning par×protocolo não bloqueia — soberania do usuário: CTA "Continuar assim mesmo" disponível. Fonte: [pancake adicionar-liquidez § Oportunidade — Validação par↔protocolo inline] — Kotai herda a oportunidade e mantém respeito à soberania.

🔴 Corrige

Seleção de protocolo como caixa-preta técnica sem pedagogia → Card de protocolo recomendado por par com justificativa em dados observados; cards manuais com label de consequência + sub-label técnico. Fonte: [pancake adicionar-liquidez § Fricção estrutural — Seleção de protocolo como caixa-preta técnica] + [uniswap-final § Fricção 1 — Léxico de protocolo]
Nomenclatura como progressão linear ("V2 < V3 < Infinity implica hierarquia de qualidade crescente") → Cards com nome de consequência ("Simples e passivo", "Concentrado num range"); "Infinity" não aparece como opção superior, mas como "Customizável (avançado)" com aviso de perfil. Fonte: [pancake adicionar-liquidez § Fricção estrutural — Nomenclatura como progressão linear]
Filtros de pool com vocabulário intraduzível (CLAMM, LBAMM) → Labels por consequência financeira; nome técnico apenas como sub-label em cinza. Fonte: [pancake adicionar-liquidez § Fricção estrutural — Componente de filtro de pool: vocabulário intraduzível]
Localização incompleta (inglês técnico dentro de UI PT-BR) → Todo copy desta tela em PT-BR; termos técnicos (V2, V3, StableSwap, Infinity) apenas como sub-labels. Fonte: [pancake-final § Fricção 2 — i18n parcial]
Protocolo exibido como decisão de primeira tela antes do par → Protocolo aparece apenas após o par ser selecionado — recomendação contextual, não pré-requisito. Fonte: [pancake adicionar-liquidez § Oportunidade — Entrada por intenção: protocolo recomendado por par]

🟡 Captura

Pilar 1 — Naming system: labels primários = consequência do usuário ("Simples e passivo", "Concentrado num range"); termos técnicos (V2, V3) apenas como sub-labels. [pancake-final § Pilar 1]. Hipótese: usuário que não conhece V2/V3 decide pelo perfil de gestão que quer, não por nomenclatura de protocolo.
Pilar 2 — CTA dinâmico + Default contextual: protocolo pré-selecionado por heurística de par + fee tier pré-selecionada por volume observado; justificativa em dado concreto ("72% do volume ativo"). [pancake-final § Pilar 2]. Hipótese: recomendação ancorada em dado observado tem mais credibilidade que recomendação editorial — e converte mais do que ausência de recomendação.
Pilar 4 — Educação contextual: descrição de consequência inline em cada card de protocolo; link "Como funciona este protocolo?" por opção; warning de par×protocolo com contexto da consequência. [pancake-final § Pilar 4]. Hipótese: iniciante que lê "exige rebalanceamento eventual" antes de escolher V3 não é surpreendido depois — reduz abandono no fluxo de configuração de range.
Pilar 7 — Curadoria opinionada: recomendação ativa (não neutral) com critério explícito em dado observado; seleção manual colapsada por default mas disponível. [pancake-final § Pilar 7]. Hipótese: protocolo recomendado por par é o diferencial de posicionamento "DEX que orienta iniciante na escolha de protocolo, não só expõe opções".
Warning par×protocolo incompatível inline — antes do aporte, sem modal separado. [pancake adicionar-liquidez § Oportunidade — Validação par↔protocolo inline]. Hipótese: iniciante que seleciona BNB+CAKE em StableSwap hoje incorre em perda estrutural silenciosa — warning inline com alternativa concreta elimina esse caso sem bloquear o avançado.

⚪ Novo

Chips qualitativos de atalho no estado vazio ("Stablecoins", "Blue-chip", "Recentes") no seletor de par. Não aparece nos relatórios como feature de entrada para adicionar liquidez. Justificativa: usuário que entra sem contexto de pool precisa de um ponto de partida sem ter que digitar — chips qualitativos reduzem cognitive load inicial em linha com curadoria opinionada (Pilar 7). Custo: 3 strings de UI a mais + i18n. Evidência futura a coletar: telemetria de uso dos chips vs busca livre; se uso for marginal, remover.
Fee tier pré-selecionada por volume observado (não por default fixo de produto). Não aparece explicitamente nos relatórios, mas deriva da oportunidade de "recomendação por par" + Pilar 2 (default contextual). Justificativa: a fee tier com maior volume observado para o par é a mais relevante para o LP iniciante — default por dado observado é mais informado que default editorial fixo. Risco: API de dados de volume por par requer custo de infra; se falhar, cai no fallback V2/0,3%. Evidência futura: taxa de modificação de fee tier pré-selecionada vs confirmação sem mudança.

Trade-offs e segunda ordem

Heurística de protocolo por par: se a classificação estiver errada (par classificado como estável quando não é), prejudica o usuário mais que a ausência de recomendação. Custo recorrente de manutenção da heurística + revisão quando distribuição de volume mudar. Mitigação: começar com heurísticas conservadoras (pares estáveis = apenas stablecoins canônicas como USDC/USDT) e ampliar gradualmente com dados.
Cards de protocolo com label de consequência exigem copywriting especializado + validação com usuário real. Simplificação excessiva pode induzir erro diferente do original (ex.: "Simples e passivo" pode levar o usuário a achar que V2 é "melhor para iniciante" quando o par pode ter liquidez V3 muito superior).
Warning par×protocolo impróprio: exige classificação de par (estável/volátil/correlacionado) — custo de manutenção similar à heurística de recomendação. CTA "Continuar assim mesmo" pode ser percebido pelo avançado como paternalista — mitigado pela ausência de bloqueio e pela clareza do CTA.
Fee tier pré-selecionada por API de dados: se a API falhar, a justificativa da recomendação ("72% do volume ativo") não pode ser exibida → toda a tela degrada para fallback V2, perdendo o diferencial. Custo de disponibilidade de dados real; fallback deve ser claro e não silencioso.
Chips qualitativos no estado vazio adicionam superfície de decisão ao formulário; se não forem usados, viram ruído — evidência futura determinará se sobrevivem.
Seletor de protocolo manual colapsado por default: usuário que não sabe que pode escolher manualmente pode não descobrir a opção. Mitigação: link "Ver outras opções ▾" é visível abaixo do card recomendado, sem precisar procurar.
Mais estado de componente (card recomendado em 3 estados: loading / pré-confirmado / seleção manual) → mais sincronização de estado de UI → mais cobertura de testes. Custo de implementação real.

Conflitos de pilar resolvidos

Pilar 1 (naming system: label primário = consequência) vs legibilidade técnica para intermediário: intermediário que conhece "V3" não encontra imediatamente a label que espera. Resolvido por sub-label técnico visível (cinza, mas presente) ao lado de cada card de consequência — hierarquia de pilar 1 vence, mas sem esconder o nome técnico.
Pilar 2 (default contextual: recomendar protocolo ativo) vs Pilar 7 (curadoria opinionada: orientar sem impor): protocolo recomendado é exibido como sugestão ativa (não campo pré-preenchido bloqueado) — usuário pode mudar sem fricção. Pilar 7 (curadoria) vence no default; Pilar 2 (contextual) determina o critério do default (volume observado). Ambos ativos sem conflito: curadoria opinionada + critério contextual + seleção manual disponível.
Pilar 3 (defesa em camadas: warning de par×protocolo) vs A3 (armadilha: solução pior que o problema): warning não bloqueia e não empilha modal sobre modal — aparece inline na mesma tela. Avança sem bloqueio via "Continuar assim mesmo". Warning só dispara para combinações objetivamente impróprias (critério revelado ao usuário), não para toda seleção manual.

Pools — Tela 4 — Definir faixa e valores de aporte (V3)

Função da tela

Segunda etapa do fluxo de adição de liquidez em V3: o usuário (foco em iniciante) configura a faixa de preço em que sua liquidez ficará ativa e define os valores de cada token a depositar — orientado por presets de estratégia com justificativa pedagógica, sem precisar entender "ticks" ou "concentrated liquidity" em termos técnicos. Intermediário como segundo perfil, com modo "Personalizar" disponível para controle granular total.

Variação de protocolo: esta tela propõe o caminho V3 (recomendação de pools-03 para pares blue-chip como ETH/USDC). Para V2/StableSwap, o seletor de faixa não aparece e o stepper rotula o passo como "Inserir valores" em vez de "Definir faixa e valores" — o formulário adapta-se ao protocolo sem campos irrelevantes.

Componentes / elementos

Estrutural (define o paradigma da tela)

Stepper de progressão
- Três passos visíveis no topo, com labels que refletem o que realmente acontece:
  - ✓ Passo 1 de 3: Par e protocolo (concluído)
  - → Passo 2 de 3: Definir faixa e valores (atual)
  - Passo 3 de 3: Revisar e confirmar
- Chip de resumo do que foi decidido: ETH/USDC · V3 · 0,05% — link "← Voltar" no chip navega para pools-03 preservando par selecionado (context-preserving back, não destruição de estado).
- Label do Passo 2 varia conforme protocolo: V3/Infinity → "Definir faixa e valores"; V2/StableSwap → "Inserir valores".
Chip-strip de saúde do pool (herdado de pools-02, persistente durante todo o fluxo)
- Linha horizontal compacta acima do seletor de faixa: Rend. est. (7d) 12,4% · TVL R$ 135 M · Vol. 24h ↑1,3%
- Nenhuma decisão de range acontece sem o contexto de saúde do pool estar visível.
- Cor: neutro (cinza) em pool saudável; âmbar em pool com sinal de atenção; vermelho em pool morta.
- Tap em qualquer métrica → bottom sheet com narrativa do KPI (mesma interação de pools-02).
- Pool morta (Vol/TVL < 0,01 por ≥ 7d): strip em âmbar + aviso colapsável expandido: "Pool com atividade muito baixa nas últimas semanas. O rendimento estimado pode não se confirmar."

Seletor de estratégia de faixa (componente central da tela — V3 apenas)

Quatro opções em cartões empilhados (1 coluna em mobile, 2 colunas em desktop):

Cartão	Label principal	Descrição inline	Sub-label técnico
Faixa total	Sem gestão de faixa	Liquidez ativa em qualquer preço. Rendimento menor, posição não expira. Parecido com V2 em comportamento.	`0 → ∞`
±10% do preço atual	Faixa moderada (default)	Rendimento maior que faixa total. Posição para se o preço sair ~10%. Gestão ocasional.	`R$ 16.689 – R$ 20.397`
±5% do preço atual	Faixa estreita	Rendimento alto quando ativo. Expira com frequência — exige atenção regular.	`R$ 17.616 – R$ 19.470`
Personalizar	Definir manualmente	Para usuário avançado. Define preço mínimo e máximo exatos.	—

Default pré-selecionado: "±10% do preço atual" com badge Recomendado para iniciante + justificativa: "Boa faixa de partida: rendimento maior que faixa total com gestão menos frequente que faixa estreita."
Tap em qualquer cartão o seleciona; feedback visual imediato (preenchimento, borda de cor).
Ao selecionar "Personalizar": dois inputs expandem abaixo — "Preço mínimo" e "Preço máximo" em R$ (alternável para unidade do par via toggle R$ ↔ ETH).

Visualização da faixa (mini-chart de contexto)
- Gráfico de velas simples do par (últimos 7 dias) com área sombreada colorida indicando a faixa ativa.
- Linha vertical de "Preço atual" em destaque: 1 ETH = R$ 18.543,20 (locale PT-BR, vírgula decimal).
- Área sombreada atualiza em tempo real conforme a estratégia de faixa muda.
- Em mobile: tap-and-stick — dedo arrastado mostra o preço do candle naquele ponto (não hover-only).
- Quando faixa é "Faixa total": área sombreada cobre toda a extensão do gráfico.
- Quando range é single-asset (min > preço atual ou max < preço atual): área fora do gráfico + aviso inline (ver estado abaixo).
- Caption abaixo do chart: "A área colorida mostra onde sua posição vai gerar rendimento. Fora dela, o rendimento para até você ajustar a faixa."
Preview de IL contextual (educação no ponto de decisão — Pilar 4)
- Caption dinâmica abaixo do seletor, gerada conforme a estratégia ativa — máximo 5 templates conservadores:
  - Faixa total: "Sem expiração de posição. Impermanent loss (IL) proporcional à variação de preço — similar ao V2 padrão."
  - ±10%: "Se o preço sair desta faixa, sua posição para de gerar rendimento até você ajustar. ETH/USDC saiu de uma faixa de ±10% em aproximadamente 40% dos dias no último mês."
  - ±5%: "Faixa estreita: maior eficiência quando ativa, mas ETH/USDC sai desta faixa com frequência. Posição pode expirar toda semana."
  - Personalizar: caption atualiza quando min e max ficam definidos — usa a faixa percentual calculada para gerar o template adequado.
- Link pedagógico sempre visível: "O que é impermanent loss? ⓘ" → bottom sheet com explicação em 3–4 linhas + link para simulador de IL.
Campos de valor de aporte
- Dois campos paralelos em card: Token A (ETH) e Token B (USDC).
- Saldo disponível como label acima de cada campo: Disponível: 2,34 ETH / Disponível: R$ 4.567,00.
- Presets chips: 25% / 50% / 75% / Máx. em ambos os campos.
  - Mobile: tap-targets com largura mínima de 44px.
  - Desktop: hover no chip mostra valor absoluto antes do clique em tooltip: "50% = 1,17 ETH ≈ R$ 21.695".
  - Chips com saldo = 0 (sem wallet conectada): estilo outline com opacidade 60%; tap dispara "Conecte sua carteira para usar atalhos de percentual."
- Eyebrow USD abaixo de campo em unidade não-fiat: ≈ R$ 21.695 sob o campo ETH, atualizado em tempo real com oracle fresco. Quando oracle > 30s: valor em cinza com asterisco + "Preço pode estar desatualizado."
- Proporção automática: preencher Token A calcula Token B com base na faixa selecionada e no preço atual. Editar Token B recalcula Token A em consequência. Quando a proporção calculada exceder o saldo disponível, o campo excedente fica com borda âmbar + ⚠ Saldo insuficiente.
- Range single-asset (faixa completamente acima ou abaixo do preço atual): apenas um campo ativo. O outro fica desabilitado com label contextual: "Nesta faixa, somente ETH entra na posição." — nunca campo cinza mudo.
Estimativa de custo total + gas
- Linha de resumo acima do CTA: Total: ~R$ 43.390 em tokens + ~R$ 8,40 em gas
- Gas em R$ — nunca em GWEI (Pilar 5).
- Timestamp do gas estimate: Estimativa às 14:32 · atualiza a cada 30s.
- Gas excepcionalmente alto: badge âmbar + "Gas elevado agora. Transação pode custar mais que o estimado."
- Gas muito baixo (< limiar de execução segura): badge âmbar + "Gas estimado pode ser insuficiente. Transação pode não executar. Ajuste em Configurações avançadas."
CTA de progressão (sticky rodapé em mobile, inline em desktop)
- CTA: "Continuar →" → avança para pools-05.
- Estados com label contextual (nunca cinza mudo):
  - Sem estratégia de faixa selecionada: "Escolha uma estratégia de faixa"
  - Faixa selecionada, sem valor: "Insira o valor de aporte"
  - Valor < mínimo do pool: "Valor mínimo de aporte: R$ 10,00"
  - Saldo insuficiente em token específico: "Saldo de ETH insuficiente" ou "Saldo de USDC insuficiente"
  - Range inválido (min ≥ max): "Preço mínimo deve ser menor que o máximo"
  - Sem wallet: "Conectar carteira para continuar"
  - Tudo pronto: "Continuar →" ativo

Cosmético (polish, vai depois do estrutural)

"Configurações avançadas" ▾ — colapsado por default; expande para:
- "Tolerância de variação de preço" (não "Slippage") — chip "Auto" com tooltip: "Auto: calculado com base na profundidade do pool e na volatilidade recente. Para este par: 0,5%." Slippage adaptativo ao par — não constante fixa.
- "Transação expira após" (não "Prazo final") — default 30 minutos; chips 15 min / 30 min / 1h.
- "Configurações avançadas" persiste expandida por device para quem já utilizou — não fecha no próximo acesso.
Badge "Recomendado para iniciante" no cartão ±10% — visual compacto, sem texto longo.

Regras de negócio

Contexto herdado de pools-03 (obrigatório): par, versão e fee tier chegam pré-definidos. Se o usuário entrar diretamente em pools-04 sem contexto, redireciona para pools-03 com mensagem: "Comece pelo par e protocolo."
Cálculo de faixa percentual: ±10% e ±5% são calculados sobre o preço atual do oracle no momento da renderização. Quando o preço se move, a faixa absoluta nos campos "Preço mínimo" / "Preço máximo" atualiza. Se o preço mudar mais de 2% enquanto o usuário preenche valores, um aviso discreto: "O preço atual mudou. Faixa atualizada."
Proporção automática V3: a razão ETH:USDC no aporte depende da posição do preço atual dentro da faixa definida. Se preço = centro da faixa → 50%/50%. Se preço próximo do mínimo → mais ETH. Se preço próximo do máximo → mais USDC. O sistema calcula; usuário nunca precisa fazer a conta.
Range single-asset: se preço atual estiver 100% abaixo do mínimo definido → posição entra 100% em USDC. Se 100% acima do máximo → 100% em ETH. O campo inativo é desabilitado com label contextual explicando por quê.
Pool sem histórico (novo par ou pool com < 30 dias): o mini-chart exibe apenas os dados disponíveis + badge "Histórico limitado". O preview de IL usa o template genérico sem a statística de "X% dos dias saiu da faixa" (dado indisponível).
Pool ainda não existe (primeiro LP do par): estado radicalmente diferente — ver Estados não-triviais. O chip-strip não exibe KPIs de pool; exibe: "Você será o primeiro provedor. Você define o preço inicial do par." Warning obrigatório: "Definir o preço inicial incorretamente pode resultar em perda imediata por arbitragem."
Adaptação de protocolo: campo de range não aparece em V2 e StableSwap. A tela nesse caso tem apenas campos de valor + estimativa de custo. Nenhum campo irrelevante é exibido; nenhuma seção é ocultada silenciosamente — se campo suma por conta do protocolo, um label contextual explica: "V2 distribui liquidez em todos os preços — sem necessidade de definir faixa."
URL como state machine: par, protocolo, fee tier, estratégia de faixa e valores são parametrizados na URL. Setup linkável — usuário pode compartilhar um link que pré-preenche toda a configuração. Ao navegar com browser back, o estado é preservado.

Estados não-triviais

Estado	Comportamento
Vazio — entrada sem contexto	Redireciona para pools-03: "Comece escolhendo o par e o protocolo."
Loading — oracle de preço	Skeleton no chip-strip + mini-chart + campos de valor. Label: "Carregando dados do pool ETH/USDC…" CTA desabilitado: "Buscando dados do pool…"
Oracle stale (> 30s)	Campos de valor exibem eyebrow USD em cinza com "Preço desatualizado · Reconectando…". CTA continua disponível com aviso: "Preço pode ter mudado. Confirme na próxima tela."
Range inválido (min ≥ max em "Personalizar")	Borda vermelha nos inputs + label: "Preço mínimo deve ser menor que o máximo." CTA desabilitado.
Range single-asset (faixa descolada do preço atual)	Área sombreada do chart some. Um campo de valor é desabilitado com label contextual. Badge âmbar: "Sua posição entra com apenas um token nesta faixa." Não bloqueia — é escolha válida para LP direcional.
Pool ainda não existe (primeiro LP)	Chip-strip substitui KPIs por: "Você será o primeiro provedor. Defina o preço inicial de 1 ETH em USDC." Campo de "Preço inicial" aparece em vez de mini-chart histórico. Warning obrigatório expandido: "Preço inicial incorreto pode resultar em perda imediata por arbitragem." CTA: "Continuar com preço inicial →"
Saldo insuficiente	Campo do token deficitário com borda âmbar + `⚠ Saldo insuficiente`. CTA desabilitado com label: "Saldo de [token] insuficiente."
Saldo insuficiente para gas	Aviso na linha de estimativa de custo: "Saldo de ETH insuficiente para pagar o gas (~R$ 8,40). Seu aporte de ETH está próximo do máximo disponível." CTA desabilitado.
Sem wallet conectada	Chip-strip mostra métricas do pool (dados públicos). Campos de valor exibem saldo como `—`. Chips de percentual em outline com opacidade 60%. CTA: "Conectar carteira para continuar."
Pool morta (Vol/TVL < 0,01 por ≥ 7d)	Chip-strip em âmbar. Banner colapsável expandido por default: "Pool com atividade muito baixa. O rendimento estimado pode não se confirmar." Não bloqueia aporte.
Gas excepcionalmente alto	Badge âmbar na linha de estimativa: "Gas elevado agora. Transação pode custar mais que o estimado." CTA disponível.
Preço moveu durante o preenchimento (> 2%)	Toast não intrusivo: "O preço atual mudou. Faixa e proporção atualizados." Campos recalculam automaticamente sem perder o valor inserido pelo usuário.

Microcopy crítico (PT-BR)

Elemento	Texto
Breadcrumb	Ganhar rendimento › ETH/USDC › Adicionar liquidez
Chip de contexto do passo anterior	ETH/USDC · V3 · 0,05% · ← Voltar
Stepper passo 2 (V3)	Definir faixa e valores
Stepper passo 2 (V2)	Inserir valores
Cartão Faixa total	Sem gestão de faixa
Cartão Faixa total — descrição	Liquidez ativa em qualquer preço. Rendimento menor, posição não expira. Parecido com V2 em comportamento.
Cartão ±10% — label	Faixa moderada
Cartão ±10% — badge	Recomendado para iniciante
Cartão ±10% — justificativa	Boa faixa de partida: rendimento maior que faixa total com gestão menos frequente que faixa estreita.
Cartão ±5% — label	Faixa estreita
Cartão ±5% — descrição	Rendimento alto quando ativo. Expira com frequência — exige atenção regular.
Cartão Personalizar — label	Definir manualmente
Caption do chart	A área colorida mostra onde sua posição vai gerar rendimento. Fora dela, o rendimento para até você ajustar a faixa.
Preço atual	1 ETH = R$ 18.543,20
Preview IL — ±10%	Se o preço sair desta faixa, sua posição para de gerar rendimento até você ajustar. ETH/USDC saiu de uma faixa de ±10% em aproximadamente 40% dos dias no último mês.
Link pedagógico	O que é impermanent loss? ⓘ
Saldo disponível	Disponível: 2,34 ETH
Eyebrow USD	≈ R$ 21.695
Range single-asset (campo inativo)	Nesta faixa, somente ETH entra na posição.
Estimativa de custo	Total: ~R$ 43.390 em tokens + ~R$ 8,40 em gas
Timestamp gas	Estimativa às 14:32 · atualiza a cada 30s
Gas elevado	Gas elevado agora. Transação pode custar mais que o estimado.
Tolerância de variação de preço (avançado)	Tolerância de variação de preço
Slippage Auto tooltip	Auto: calculado com base na profundidade do pool e na volatilidade recente. Para este par: 0,5%.
Deadline (avançado)	Transação expira após
CTA — sem faixa	Escolha uma estratégia de faixa
CTA — sem valor	Insira o valor de aporte
CTA — saldo insuficiente	Saldo de ETH insuficiente
CTA — sem wallet	Conectar carteira para continuar
CTA — pronto	Continuar →
Primeiro LP — chip-strip	Você será o primeiro provedor. Defina o preço inicial de 1 ETH em USDC.
Primeiro LP — warning	Preço inicial incorreto pode resultar em perda imediata por arbitragem. Revise com cuidado antes de continuar.
Adaptação V2 (campo de range ausente)	V2 distribui liquidez em todos os preços — sem necessidade de definir faixa.
Oracle stale	Preço desatualizado · Reconectando…
Preço moveu	O preço atual mudou. Faixa e proporção atualizados.

Rastreabilidade obrigatória

🟢 Herdado

Stepper com labels adaptados ao protocolo: rótulo do Passo 2 muda entre "Definir faixa e valores" (V3) e "Inserir valores" (V2). Fonte: [uniswap/_consolidado/nova-posicao.md § Insight — Stepper pedagógico e contextual]. Kotai herda o padrão e estende para 3 passos (par/protocolo separado do range em pools-03).
Adaptação honesta do formulário ao protocolo: campo de range ausente em V2/StableSwap; microcopy contextual explica o que sumiu e por quê. Fonte: [pancake/_consolidado/adicionar-liquidez.md § Insight — Adaptação honesta do formulário ao protocolo].
Microcopy inline pedagógica: instrução de campo sempre visível abaixo do label, não enterrada em tooltip. Fonte: [uniswap/_consolidado/nova-posicao.md § Insight — Microcopy pedagógica inline].
Feedback visual explícito de estado: botão CTA com label contextual; chips de percentual com estilo diferente quando sem saldo; campo inativo com label descritivo. Fonte: [uniswap/_consolidado/nova-posicao.md § Insight — Feedback visual explícito de estado].
Presets chips 25% / 50% / 75% / Máx. em campos de aporte: elimina cálculo cognitivo de "quanto é 50% do meu saldo". Fonte: [uniswap/_consolidado/visualizar-pool.md § Insight — Presets chips em qualquer decisão financeira].
Chips de percentual com estado honesto (outline + opacidade 60% sem wallet): tap dispara prompt de conexão, não quebra silenciosa. Fonte: [uniswap/_consolidado/visualizar-pool.md § Fricção estrutural — Affordance sem estado honesto].
Tap-and-stick no mini-chart em mobile. Fonte: [pancake-final § Pilar 5 — Mobile-first interaction].
Chip-strip de saúde persistente (herdado de pools-02): nenhuma decisão de range acontece sem APR, TVL e Vol. visíveis. Fonte: [uniswap/_consolidado/visualizar-pool.md § Oportunidade — Contexto persistente no ato de operar].
Gas estimado em R$, nunca em GWEI. Fonte: [pancake-final § Pilar 5 — Localização BR/LatAm como infraestrutura].
Eyebrow USD abaixo de campo em unidade não-fiat. Fonte: [uniswap/_consolidado/visualizar-pool.md § Fricção estrutural — Unidade técnica não traduzida para intuitiva] + [uniswap/_consolidado/visualizar-pool.md § Oportunidade — Tradução técnica→intuitiva].
CTA desabilitado com label contextual (nunca cinza mudo). Fonte: [uniswap-final § Insight — Estados como instrução acionável] + [pancake-final § Pilar 2 — CTA dinâmico].
"Tolerância de variação de preço" (não "Slippage") como label de setting — problema que resolve, não nome técnico. "Transação expira após" (não "Prazo final") — preposição elimina ambiguidade relativo/absoluto. Fonte: [uniswap/_consolidado/nova-posicao.md § Fricção — Affordance e semântica ambígua em campos de decisão financeira].

🔴 Corrige

Fricção — Versão como caixa-preta técnica sem pedagogia → Protocolo já foi decidido e pedagógico em pools-03; nesta tela, o campo de range adapta-se ao protocolo com label contextual se sumir. [uniswap/_consolidado/nova-posicao.md § Fricção — Versão como caixa-preta] + [pancake/_consolidado/adicionar-liquidez.md § Fricção — Seleção de protocolo como caixa-preta técnica]
Fricção — Ausência de estado do pool na janela de decisão de aporte → Chip-strip de saúde persiste no topo desta tela; pool morta ganha banner expandido por default. [uniswap/_consolidado/nova-posicao.md § Fricção — Ausência de estado do pool destino]
Fricção — Chips de percentual com false affordance (habilitados com saldo 0) → Estilo diferente quando sem wallet + tap dispara prompt contextual. [uniswap/_consolidado/visualizar-pool.md § Fricção — Affordance sem estado honesto]
Fricção — Unidade técnica sem tradução para intuitiva → Eyebrow USD abaixo de todo campo em unidade não-fiat; gas em R$. [uniswap/_consolidado/visualizar-pool.md § Fricção — Unidade técnica não traduzida]
Fricção #2 — i18n parcial → Todo copy desta tela em PT-BR; gas em R$; formato numérico locale BR (R$ 18.543,20, não $18,543.20). [pancake-final § Fricção 2 — i18n parcial]
Fricção — "30 minutes" não traduzido / ambíguo como absoluto → Label "Transação expira após" + unidade em português. [uniswap/_consolidado/nova-posicao.md § Ponto isolado — "30 minutes" não traduzido]

🟡 Captura

Pilar 7 — Curadoria opinionada: presets de estratégia de faixa — em vez de expor campos técnicos de "tick inferior / tick superior", o produto oferece 3 presets nomeados por consequência (Sem gestão / Faixa moderada / Faixa estreita) + Personalizar opt-in. Default é o preset de menor risco de gestão para o iniciante. [pancake-final § Pilar 7] + [uniswap/_consolidado/nova-posicao.md § Oportunidade — Pedagogia de versão: cartões de trade-off]. Hipótese: iniciante que escolhe "Faixa moderada" cria posição mais adequada ao seu perfil de gestão do que iniciante que enfrenta campo de min/max em preço absoluto sem referência.
Pilar 4 — Educação contextual: preview de IL no ponto de decisão — caption dinâmica gerada pela estratégia de faixa selecionada + estatística histórica de frequência de saída do range. [pancake-final § Pilar 4] + [uniswap/_consolidado/pools.md § Sistema pedagógico de métricas DeFi]. Hipótese: iniciante que lê "ETH/USDC saiu de ±10% em ~40% dos dias" calibra expectativa de gestão antes de aportar — reduz abandono confuso de posições expiradas.
Pilar 5 — Localização BR/LatAm: todos os valores monetários em R$ — gas, total de aporte, eyebrow USD, preço atual do par. [pancake-final § Pilar 5]. Hipótese: usuário BR toma decisão de aporte na moeda que entende sem conversão mental.
Slippage adaptativo ao par/pool em "Configurações avançadas" (não constante fixa) — tooltip expõe o critério: "Para este par: 0,5%." [uniswap/_consolidado/nova-posicao.md § Oportunidade — Slippage adaptativo ao par/pool]. Hipótese: slippage calibrado por profundidade + volatilidade do par reduz transações falhas em pool com baixa liquidez e reduz exposição a MEV em pool líquida.
URL como state machine — toda a configuração (par, protocolo, fee, estratégia de faixa, valores) parametrizada na URL. [uniswap/_consolidado/nova-posicao.md § Observações — URL como state machine]. Hipótese: setup de LP shareable por link reduz custo de suporte ("como eu reproduzo o que estava fazendo?") e viabiliza deep-link de campanhas de liquidez.

⚪ Novo

Presets de estratégia por percentual do preço atual (±10%, ±5%) em vez de campos de "ticks" ou preços absolutos. Não aparece explicitamente nos relatórios como feature de range selector — os relatórios identificam a fricção (range como caixa-preta técnica) e a oportunidade (pedagogia de versão por cartões de trade-off), mas a solução de "presets de faixa percentual com nome de consequência" é síntese nova. Justificativa: o ticks interface é inacessível para iniciante (requer entender log-space de preço em AMM V3); preços absolutos dependem de conhecimento de "quanto é razoável para ETH/USDC", que o iniciante não tem. Faixa percentual do preço atual é uma âncora relativa que o usuário pode raciocinar ("±10% significa que posso aguentar ETH subir ou cair 10% antes de precisar agir"). Risco: percentual fixo não respeita a matemática de tick espaçamento do V3 — a conversão para min/max absoluto pode resultar em preços ligeiramente desviados dos ticks disponíveis. Mitigação: arredondar para o tick mais próximo com tooltip: "Preço mínimo ajustado para o intervalo de tick disponível: R$ 16.689." Evidência futura a coletar: taxa de modificação dos presets vs uso de "Personalizar"; se iniciante modifica preset com frequência, o default de ±10% pode precisar de ajuste.
Estatística de frequência de saída do range na caption de IL (ex: "ETH/USDC saiu de ±10% em ~40% dos dias no último mês"). Deriva de Pilar 4, mas a feature de calcular e exibir frequência histórica de range breach não está documentada nos relatórios. Justificativa: é o único dado que traduz "risco de expiração de posição" para o iniciante de forma concreta — substituível por heurística qualitativa ("com frequência" / "raramente") se o cálculo for caro. Risco: dado desatualizado pode criar expectativa errada — aceitar exibindo janela de cálculo: "frequência nos últimos 30 dias". Evidência futura: custo de query vs adoção do dado pelo usuário.

Trade-offs e segunda ordem

Presets de faixa percentual exigem conversão para ticks do V3. Risco de arredondamento para tick disponível gerar preço ligeiramente diferente do percentual declarado. Custo: lógica de conversão percent→tick + tooltip de ajuste. Alternativa de fallback: exibir o preço absoluto resultante antes de avançar para que o usuário confirme.
Preview de IL com frequência histórica de range breach exige query de dados históricos de preço por par + janela de 30 dias. Custo de infra real. Fallback aceitável: remover a estatística e usar copy qualitativo ("com frequência", "raramente") se o cálculo for caro.
Chip-strip de saúde mais presets mais mini-chart mais IL preview = muita informação acima dos campos de valor. Risco de cognitive overload. Mitigação: hierarquia visual clara (strip compacto 1 linha → presets em 4 cartões → chart contextual → IL caption → campos de aporte) — o usuário processa em sequência, não em paralelo.
Slippage adaptativo depende de oráculo de profundidade de pool + volatilidade 24h em tempo real. Latência > 2s no cálculo bloqueia o CTA ("Calculando tolerância…") — custo de UX se o cálculo for lento. Fallback: usar constante por bucket de liquidez (pool > 1M TVL → 0,5%; pool < 100k TVL → 2,5%).
URL como state machine exige que o roteador do frontend suporte parâmetros deep-linkados para o formulário. Custo de implementação pontual, mas valor recorrente (suporte, compartilhamento, campanha).
Primer LP (pool inexistente) tem UX radicalmente diferente da maioria dos casos — risco de implementar estados adicionais que aumentam complexity sem uso frequente. Evidência futura: taxa de criações de novos pools vs adições a pools existentes para calibrar prioridade de implementação.

Conflitos de pilar resolvidos

Pilar 7 (curadoria opinionada: default o menor risco) vs Pilar 2 (contextual: default pelo caso mais comum do par): ±10% como default combina os dois — é o preset mais usado por pares blue-chip voláteis (contextual) e o que exige menos gestão ativa entre os presets não-triviais (pró-iniciante). Conflito ausente neste caso; os dois pilares convergem.
Pilar 4 (educação contextual: mostrar IL e frequência de range breach) vs A2 (sobre-escopar a tela: esta tela é de configuração, não de educação): IL preview é contextual ao ponto de decisão de range — é parte da tela, não funcionalidade de outra tela. A regra A2 proíbe features de outro fluxo, não educação inline sobre a decisão corrente. Decisão: mantém IL preview como componente desta tela.
Pilar 3 (defesa em camadas: warning de pool morta) vs A3 (solução pior que o problema: paternalismo): warning de pool morta expande por default em pool crítica mas permanece colapsável e não bloqueia o aporte. Soberania do usuário preservada; Pilar 3 implementado como informação acessível, não barreira.

Criar Pool — Tela 02: Configuração da posição e valores de aporte

1. Função da tela

Permite que o usuário configure os parâmetros específicos da sua posição (faixa de preço quando aplicável, valor de aporte de cada token) com visibilidade do estado atual do pool e feedback preditivo de resultado. Foco: intermediário para o modo Concentrada; iniciante para o modo Simples.

2. Componentes / elementos

Esta tela tem dois layouts conforme o modo escolhido na Tela 01. O layout Simples é apresentado primeiro; o Concentrada, em seguida. Modo Programável compartilha o layout Concentrada com adição de uma seção de configuração de hook ao final (não detalhada nesta proposta — escopo de uma tela futura).

Layout A — Modo Simples (V2)

Estruturais

2.A.1 Card de saúde do pool (propagado da Tela 01, agora sempre expandido na Tela 02) Exibe TVL, Volume 24h + variação, APR estimado (7d), badge de atividade, e — quando pool é novo — o aviso de "você define o preço inicial" expandido com o campo de preço inicial editável.

2.A.2 Campos de aporte Dois campos empilhados verticalmente (Token A / Token B). Cada campo:

Ícone + símbolo do token
Input numérico com separador decimal PT-BR (vírgula)
Equivalente em BRL/USD ao lado do valor digitado
Label "Saldo disponível: X [Token]" clicável (fill-max)
Botão "Máximo" inline à direita

Acoplamento de campos: Ao digitar em Token A, Token B auto-preenche conforme o ratio de preço atual do pool. Ao digitar em Token B, Token A auto-preenche. Um ponto de entrada altera o outro. Exceção: pool novo — ambos os campos são independentes; o usuário define o aporte em cada token livremente; a razão entre eles determina o preço inicial do pool.

2.A.3 Resumo de custo e proteção Abaixo dos campos de aporte:

Linha "Proteção de slippage:" + chip "Auto ([valor]%)" + ícone ⓘ
Ao clicar no chip: popover com campo de input manual de slippage + opção "Voltar para Auto". Fora do popover: aplica o valor. Sem tela de settings separada.
Linha "Sua transação expira após:" + valor "30 minutos" (label relativo, não absoluto — endereça ambiguidade de "prazo final da transação" do Uniswap)

Cosméticos

2.A.4 Stepper — Etapa 1 ativa. Etapa 2 futura. 2.A.5 Breadcrumb — "Ganhar rendimento / Criar posição / Configurar"

Layout B — Modo Concentrada (V3)

Estruturais

2.B.1 Card de saúde do pool (mesmo componente do Layout A, sempre expandido aqui)

2.B.2 Seletor de faixa de preço

O componente mais importante desta tela. Estrutura:

Presets de faixa — 3 cards horizontais:

Label	Faixa	Indicador	Nota
"Conservadora"	±10% do preço atual	"Dentro do range ~90% do tempo (30d)"	Menor retorno/risco
"Moderada"	±30% do preço atual	"Dentro do range ~75% do tempo (30d)"	Equilíbrio
"Ampla"	Full range (sem limite)	"Sempre dentro do range"	Menor eficiência de capital

Cada preset mostra:

Label principal em PT-BR
Faixa de preço calculada (ex: "R$ 1.800 – R$ 2.200 por ETH")
Indicador preditivo: "Dentro do range ~X% do tempo (últimos 30d)" com tooltip "Baseado na volatilidade histórica 30d. Resultados reais variam."
APR estimado associado ao preset (ex: "APR estimado: 4,2% a 12,8%") com disclaimer ao hover/tap

Inputs de faixa manual (abaixo dos presets):

Dois campos numéricos: "Preço mínimo" / "Preço máximo" (em Token A por Token B)
Botão "Auto-inverter" quando ratio < 0,01 (auto-flip por magnitude)
Label abaixo: "1 [Token A] = [valor calculado] [Token B]" atualizado ao digitar

Visualização de faixa:

Barra horizontal simples mostrando: zona fora do range (cinza) / zona dentro do range (azul) / preço atual (linha vertical tracejada)
Em mobile: tap-and-stick para interação com a barra (não hover)

2.B.3 Campos de aporte (mesmo componente do Layout A) Diferença: quando o preço atual estiver fora da faixa definida pelo usuário, apenas um dos campos fica habilitado (comportamento natural de LP concentrada — o pool só aceita o token do lado do range). Exibir aviso inline: "Com esta faixa, você só aporta [Token X] até o preço entrar na faixa." Este aviso previne confusão de "por que só um campo está ativo?".

2.B.4 Seletor de fee tier (aparece apenas em modo Concentrada/V3) Segmented control horizontal com 4 chips: "0,01%" / "0,05%" / "0,3%" / "1%" — não oculto nem dropdown. Chip com maior liquidez no par selecionado recebe badge "Mais usado neste par". Tooltip de cada tier ao tocar:

0,01%: "Para pares de ativos quase idênticos (ex: USDC/USDT). Taxa muito baixa, volume alto."
0,05%: "Para pares estáveis ou muito correlacionados."
0,3%: "Para a maioria dos pares. Equilibra volume e retorno."
1%: "Para pares de baixa liquidez ou ativos exóticos. Maior retorno por swap, menor volume."

2.B.5 Resumo de custo e proteção (mesmo que Layout A)

Cosméticos

2.B.6 Stepper e Breadcrumb — iguais ao Layout A.

3. Regras de negócio

RN-09 — Propagação de contexto da Tela 01. Par, modo e estado do pool (existente saudável / inativo / novo) chegam propagados por URL ou estado de formulário. Se o usuário acessar a Tela 02 diretamente (via URL sem estado da Tela 01), redirecionar para Tela 01 com o par pré-preenchido se disponível na URL.

RN-10 — Acoplamento de campos de aporte em pool existente. Ao digitar Token A: Token B = valor Token A × (reserva Token B / reserva Token A) do pool. Ao digitar Token B: Token A = valor Token B × (reserva Token A / reserva Token B). O acoplamento respeita a composição atual do pool — não usa preço de mercado externo diretamente para evitar slippage no cálculo de preview.

RN-11 — Pool novo: campos independentes + campo de preço inicial. Quando o pool é novo (detectado na Tela 01): campo "Preço inicial: 1 [Token A] = ? [Token B]" aparece no card de saúde expandido, acima dos campos de aporte. Usuário define o preço → campos de aporte ficam independentes (qualquer ratio é aceito). Após definir o preço: se o usuário alterar Token A, Token B sugere o valor correspondente (não força). O aviso de risco de arbitragem permanece visível durante todo o preenchimento.

RN-12 — Validação de saldo. Ao blur (perda de foco) de cada campo: comparar com saldo disponível. Se valor > saldo: campo com borda vermelha + mensagem de saldo insuficiente + dois CTAs de recuperação ("Comprar com fiat" / "Ver endereço de depósito"). O CTA principal não é bloqueado ainda — o botão da tela muda para o estado de erro descrito abaixo.

RN-13 — Faixa inválida (modo Concentrada). Preço mínimo ≥ preço máximo: ambos os campos ficam com borda vermelha, aviso inline "O preço mínimo deve ser menor que o preço máximo", CTA de avanço bloqueado.

RN-14 — Faixa muito estreita (modo Concentrada): aviso preventivo. Quando faixa < 2% de largura do preço atual em par volátil (token não-stable): aviso inline não-bloqueante "Faixa muito estreita — o preço pode sair em horas. Considere ampliar a faixa." Badge na visualização de faixa muda para laranja. CTA continua habilitado.

RN-15 — Out-of-range imediata: preço atual fora da faixa definida. Se preço atual > preço máximo definido ou < preço mínimo definido: aviso proeminente acima dos campos de aporte "⚠ O preço atual está fora da sua faixa — você não ganhará taxas até o preço entrar na faixa." Um dos campos de aporte fica readonly com valor 0 (comportamento de LP concentrada fora do range). CTA continua habilitado com label "Configurar posição fora do range" (não "Configurar minha posição") para sinalizar o estado.

RN-16 — Slippage adaptativo. Valor de "Auto" calculado por: profundidade de liquidez do pool para o aporte + volatilidade 24h do par + tamanho do aporte em USD. Par estável/alta liquidez: sugestão de 0,1%. Pool morto ou baixa profundidade: sugestão de 3–5% + warning "Profundidade baixa — slippage alto esperado." Pool novo: 1% como default com aviso. Valor editável manualmente pelo usuário. Se slippage manual > 5%: warning "Slippage alto — sua transação pode ser alvo de MEV (front-running)." Se slippage manual > 15%: warning mais forte + chips de alternativa.

RN-17 — Auto-flip de preço por magnitude. Quando ratio Token A / Token B < 0,001 (ex: BTCB/USDT exibido como 0,0000X): botão "Inverter par" aparece na visualização de faixa; ao clicar, inverte a base de preço e recalcula os campos. Badge discreto "(invertido: 1 [Token B] = X [Token A])" fica visível.

RN-18 — Fee tier pré-selecionado por heurística. Fee tier com maior TVL ativo para o par selecionado é pré-selecionado. Se não houver dados (pool novo): fee tier mais comum para o tipo de par (0,3% para a maioria; 0,05% para pares estáveis). Badge "Mais usado neste par" no chip pré-selecionado.

RN-19 — CTA de avanço: condições de habilitação. Habilitado quando: par válido + campos de aporte preenchidos com valor > 0 + saldo suficiente em ambos os tokens + faixa válida (se Concentrada). Label: "Revisar posição" (não "Confirmar" — a confirmação real é na Tela 03).

4. Estados não-triviais

Vazio (campos não preenchidos): Campos de aporte em branco com placeholder "0". Botão de fill-max disponível. CTA "Inserir o valor do aporte" (disabled). Presets de faixa visíveis mas sem dados de indicador de probabilidade enquanto o aporte é zero.

Loading (carregando dados de liquidez do pool para cálculo de slippage adaptativo e indicadores de preset): Skeleton nos indicadores de preset ("Dentro do range ~?%"). Slippage exibe "Auto (calculando...)". Máximo 3s de loading; fallback: valores estimados com disclaimer "Baseado em dados de mercado. Pode variar."

Saldo insuficiente (um ou ambos os tokens): Campo com borda vermelha. Mensagem: "Saldo insuficiente de [Token]. Você tem [saldo disponível]." Dois CTAs inline: "Comprar [Token] com fiat" / "Trazer de outra carteira". CTA principal muda para "Saldo insuficiente — ajuste o valor" (disabled, laranja).

Faixa inválida (min ≥ max, modo Concentrada): Ambos os campos de faixa com borda vermelha. Mensagem inline: "O preço mínimo deve ser menor que o preço máximo." Visualização de faixa exibe estado de erro (barra vermelha). CTA bloqueado.

Out-of-range imediata (preço atual fora da faixa, modo Concentrada): Banner amarelo: "⚠ O preço atual está fora da sua faixa. Você não ganhará taxas até o preço entrar nela. [Por quê isso acontece? ▾]" Colapsável com explicação: "Em provisão concentrada, você só ganha taxas quando o preço estiver dentro da faixa que você definiu. Fora da faixa, sua posição fica ativa mas parada." CTA muda para "Configurar posição fora da faixa" — enabled, mas label diferente para sinalizar o estado.

Pool novo (par sem pool existente): Campo "Preço inicial" no card de saúde expandido. Campos de aporte independentes (sem acoplamento). Aviso permanente: "Atenção: o preço que você definir determina a taxa de câmbio inicial deste pool. Se estiver muito diferente do preço de mercado, arbitradores vão corrigir imediatamente e você pode perder parte do aporte." Tooltip "Saiba mais" explica arbitragem em 2 frases.

Slippage alto detectado (> 5%): Warning não-bloqueante: "Slippage acima de 5% — sua transação pode ser alvo de front-running (MEV)." Chips de alternativa: "Usar MEV protection" / "Reduzir aporte" / "Manter assim".

Rede errada detectada durante preenchimento: Banner no topo: "Você trocou para [Rede X]. Este pool está em [Rede Y]. Troque de volta ou comece um novo par." CTA bloqueado.

Carteira desconectada durante preenchimento: Banner no topo: "Carteira desconectada. [Reconectar]." Campos permanecem preenchidos. CTA bloqueado até reconexão.

5. Microcopy crítico

Label de seção dos campos de aporte: "Quanto você quer depositar?"

Instrução no campo de aporte: "Digite o valor e o outro campo é preenchido automaticamente."

Presets de faixa (modo Concentrada):

"Conservadora — dentro do range ~90% do tempo"
"Moderada — dentro do range ~75% do tempo"
"Ampla — sempre dentro do range (menor eficiência)"
Disclaimer abaixo dos presets: "Estimativa baseada na volatilidade dos últimos 30 dias. Resultados reais variam com as condições de mercado."

Campos de faixa manual:

Mínimo: "Preço mínimo (1 [Token A] = ? [Token B])"
Máximo: "Preço máximo (1 [Token A] = ? [Token B])"
Label abaixo: "Preço atual: 1 [Token A] = [valor] [Token B]"

Chip de slippage:

Default: "Auto (X,X%)"
Popover título: "Proteção de slippage"
Instrução no popover: "Define o quanto o preço pode mudar entre o envio e a execução. Valores muito baixos podem fazer a transação falhar; valores muito altos aumentam o risco de front-running (MEV)."
Label campo manual: "Definir slippage manualmente"
Warning slippage manual alto: "Slippage acima de 5% — risco de front-running (MEV). Use com cuidado."

Tempo da transação:

Label: "Sua transação expira após"
Valor: "30 minutos"
Tooltip: "Se a transação não for incluída num bloco em 30 minutos após o envio, ela é cancelada automaticamente. Você pode reenviar."

Aviso out-of-range: "⚠ O preço atual está fora da sua faixa. Você não ganhará taxas até o preço entrar nela."

Aviso pool novo: "Atenção: você define o preço inicial deste pool. Se estiver muito diferente do mercado, você pode perder parte do aporte por arbitragem no primeiro bloco."

Aviso faixa muito estreita: "Faixa muito estreita — o preço pode sair em horas. Considere ampliar a faixa ou usar a opção 'Moderada'."

Mensagens de saldo insuficiente: "Saldo insuficiente de [Token]. Você tem [saldo disponível] disponível."

CTA 1: "Comprar [Token] com fiat"
CTA 2: "Trazer de outra carteira"

CTA de avanço:

Disabled (campos vazios): "Inserir o valor do aporte"
Enabled: "Revisar posição"
Estado out-of-range: "Configurar posição fora da faixa"
Estado saldo insuficiente: "Saldo insuficiente — ajuste o valor" (disabled, laranja)

6. Rastreabilidade obrigatória

🟢 Herdado

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. [uniswap-nova-posicao § Pontos isolados — Tela 3: Settings de slippage/deadline em popover]
Chip "Auto" exibe o valor calculado — não esconde a heurística; "Auto: 2,5%" em vez de "Auto" opaco. [uniswap-nova-posicao § 🟢 Feedback visual explícito de estado — Tela 3: chip Auto]
CTA desabilitado com label descritivo em vez de bloqueio silencioso — "Inserir o valor do aporte" em vez de botão cinza mudo. [pancake-final § 🟢 Transparência proativa antes do CTA] + [uniswap-final § 🟢 Estados como instrução acionável]
Campos de aporte com botão "Máximo" e saldo visível — padrão presente em ambos os concorrentes, convenção válida. [uniswap-nova-posicao] + [pancake-adicionar-liquidez]
Acoplamento de Token A ↔ Token B com auto-preenchimento — convenção válida em todos os DEXes LP; quebrar seria A8. [uniswap-nova-posicao]
Equivalente USD ao lado de todo token amount — "múltiplas representações do mesmo dado". [uniswap-final § 🟢 Múltiplas representações do mesmo dado + bidirecionalidade]

🔴 Corrige

Slippage "Auto" sem critério exposto — "Auto (X,X%)" com tooltip do critério ativo: "Calculado com base na profundidade do pool e na volatilidade recente." [uniswap-nova-posicao § 🔴 Pontos isolados — Tela 3: Auto = 2,5% sem critério]
"30 minutes" não localizado + label ambíguo como deadline absoluto — corrigido para "Sua transação expira após 30 minutos" (relativo, PT-BR). [uniswap-nova-posicao § 🔴 Pontos isolados — Tela 3: "30 minutes" não traduzido] + [uniswap-nova-posicao § 🔴 Affordance e semântica ambígua — "Prazo final da transação"]
Fee tier como caixa cinza + botão "Mais ▾" sem clareza — corrigido para segmented control com 4 chips visíveis + tooltips por tier. [uniswap-nova-posicao § 🔴 Affordance e semântica ambígua — "Nível de tarifas"]
Ausência de estado do pool destino — card de saúde expandido na Tela 02, antes do commit. [uniswap-nova-posicao § 🔴 Estrutural — Ausência de estado do pool destino]
Caso "pool ainda não existe" sem UX dedicada — campo de preço inicial, aviso de risco de arbitragem, campos independentes. [uniswap-nova-posicao § Observações adicionais — Caso "pool ainda não existe"]
Gráficos hover-only inacessíveis em mobile — visualização de faixa com tap-and-stick. [pancake-final § Fricção 13 — Gráficos e métricas hover-only]
Auto-flip de preço por magnitude ausente — botão de inversão de par quando ratio < 0,001. [pancake-final § Pilar 7 — Mobile-first + BR/LatAm — auto-flip de preço por magnitude]

🟡 Captura

Presets de faixa com probabilidade e APR estimado — "Conservadora — dentro do range ~90% do tempo" em vez de geometria abstrata de ticks. [uniswap-final § Pilar 5 — Presets de range com probabilidade e APR estimado]
Slippage adaptativo ao par/pool — Auto calcula por profundidade + volatilidade + tamanho do aporte; tooltip com critério. [uniswap-nova-posicao § 🟡 Oportunidade 3 — Slippage adaptativo]
Mensagem de saldo insuficiente com duas saídas explícitas — "Comprar com fiat" / "Trazer de outra carteira" em vez de CTA único de on-ramp. [pancake-final § Pilar 6 — Card de saldo insuficiente com duas saídas]
Filtros de pool por consequência financeira — labels de fee tier por consequência ("Para pares quase idênticos") em vez de nome técnico puro. [pancake-adicionar-liquidez § 🟡 Oportunidade 2 — Filtros por consequência financeira]

⚪ Novo

Indicador "Dentro do range ~X% do tempo (30d)" nos presets: o valor percentual de probabilidade histórica de estar in-range precisa de modelo específico baseado em volatilidade histórica do par. Os consolidados identificam a oportunidade mas não especificam o cálculo. Justificativa: sem esse número, o preset é só um label qualitativo sem âncora — o iniciante não consegue diferenciar "Conservadora" de "Moderada" sem evidência numérica. Evidência a coletar: acurácia preditiva do modelo vs volatilidade realizada; % de usuários que mudam de preset após ver o indicador. Custo: modelo de simulação Monte Carlo ou lookback histórico no backend; atualização por par/período. Risco: se o número estiver errado no momento de alta volatilidade, gera desconfiança no produto. Mitigação: disclaimers sempre visíveis; usar intervalo em vez de ponto ("75–85%").
Aviso automático de faixa muito estreita em par volátil: a heurística de "< 2% de largura = faixa muito estreita" é específica da Kotai. Justificativa: previne o caso mais comum de posições concentradas mal configuradas por iniciante (faixa de ±0,1% em par com volatilidade diária de 3–5%). Evidência a coletar: % de posições criadas com faixa < 2% que saem de range em < 24h.

7. Trade-offs e segunda ordem

Dois layouts (A e B): dobra o custo de design e implementação do componente de tela. Mitigação: componentes compartilhados (card de saúde, campos de aporte, resumo de custo) extraídos para biblioteca interna; apenas o seletor de faixa e o fee tier são exclusivos do Layout B. Custo de manutenção: mudanças nos componentes compartilhados impactam ambos os layouts.

Presets de faixa com probabilidade histórica: modelo probabilístico com dependência de indexação de histórico de preço por par. Se o índice ficar desatualizado ou offline, indicadores ficam em "—" (fallback gracioso). Risco de gaming: usuários avançados podem tentar arbitrar os presets se os números ficarem estáveis — mitigado por atualização frequente (diária ou por bloco de 100 trades).

Slippage adaptativo em pool novo: sem profundidade de liquidez existente para calcular slippage, o modelo usa estimativa por tamanho de aporte + spread de mercado externo. A estimativa é intrinsecamente imprecisa para pools novos. Mitigação: label explícito "Auto (estimado para pool novo — pode variar)" + default mais conservador (1%).

Card de saúde sempre expandido na Tela 02: aumenta a altura total da tela, especialmente em mobile. Para pool inativo ou novo, o card tem conteúdo mais denso. Risco de scroll fatigue em mobile. Mitigação: card colapsável após o usuário ter interagido com ele ao menos uma vez (estado persistido por sessão).

Acoplamento Token A ↔ B + faixa out-of-range: quando o preço atual está fora da faixa, um dos campos fica readonly (valor 0). Isso pode confundir o usuário que digitou um valor e viu o campo ser zerado. Microcopy do aviso de out-of-range precisa explicar o comportamento: "Com o preço fora da sua faixa, você só deposita [Token X] agora." Custo de estado de componente: mais lógica de sincronização entre seletor de faixa e campos de aporte.

Pools — Tela 6 — Posição criada: confirmação e próximos passos

Função da tela

Estado pós-transação do fluxo de adição de liquidez: cobre a transição de "transação submetida" para "posição ativa" (ou "falhou") e, em caso de sucesso, entrega ao iniciante o onboarding de gestão específico para V3 — o que monitorar, quando agir e como gerenciar a faixa de preço — antes que ele abandone o produto sem entender o que acabou de criar. Intermediário como segundo perfil: vê o resumo da posição e navega diretamente para "Minhas posições".

Componentes / elementos

Estrutural (define o paradigma da tela)

Card de identidade da posição criada (sempre visível, independente do estado da tx)
- Par e protocolo: ETH / USDC · V3 · 0,05%
- Faixa: R$ 16.689 – R$ 20.397 (±10%)
- Valores depositados: 1,17 ETH + R$ 21.695 USDC · Total: ≈ R$ 43.390
- Rede: Ethereum (ou a rede do pool)
- Endereço da posição NFT (compacto, copiável): #123456 + ícone de cópia
- Este card existe nos três estados de transação (pendente / confirmado / falhou) — âncora de identidade que não some.
Indicador de estado da transação (componente central, muda conforme estado)

Estado A — Pendente (tx submetida, aguardando mineração):
- Ícone animado de relógio/loading (não spinner genérico — precisa ser reconhecível como "aguardando blockchain").
- Título: "Transação enviada"
- Sub-copy: "Sua posição está sendo confirmada na blockchain. Isso geralmente leva de 15 segundos a 3 minutos."
- Hash da transação compacto + link para explorer: 0xabc…def → Ver no Etherscan ↗
- Banner informativo discreto: "Você pode fechar esta tela com segurança. Sua posição aparecerá em 'Minhas posições' assim que confirmada."
- Progresso estimado: barra de progresso discreta + estimativa textual: "Estimativa: ~45 segundos". Recalcula com o tempo.
Estado B — Confirmado (tx minerada, posição ativa):
- Ícone de confirmação (checkmark ou similar — feedback visual positivo sem exagero).
- Título: "Posição criada com sucesso!"
- Sub-copy: "Sua liquidez já está ativa no pool ETH/USDC. Você começa a ganhar rendimento com cada troca feita neste par."
- Hash + link para explorer (idêntico ao estado pendente — usuário pode verificar).
Estado C — Falhou (tx revertida on-chain):
- Ícone de erro (X vermelho ou similar).
- Título: "Transação não concluída"
- Sub-copy: diagnóstico do motivo (ver estados não-triviais — nunca mensagem genérica).
- CTAs: "Tentar de novo" (primário) + "Ver detalhes do erro" (link, abre log técnico compacto para o avançado).
- Nenhum fundo foi movido — confirmação explícita: "Nenhum token saiu da sua carteira."

Bloco "O que acontece agora" — onboarding de gestão V3 (apenas no Estado B confirmado — Pilar 4)

Este bloco é a diferenciação central desta tela. Todo concorrente mostra "Transaction Submitted" e deixa o usuário à própria sorte em V3. O Kotai entrega o manual de voo antes do usuário fechar a tela:

Para faixa não-total (±10% ou ±5%):

Seção colapsável por default em intermediário; expandida por default em iniciante (heurística: primeira posição LP do usuário → expandida).
Título da seção: "Sua posição precisa de atenção às vezes"

Três itens em lista compacta com ícones:

Ícone	Situação	O que acontece	O que fazer
🟢	Preço dentro da faixa	Posição ativa — gerando rendimento a cada troca	Nada. O rendimento acumula automaticamente.
🟡	Preço se aproxima do limite	Posição ainda ativa, mas perto de expirar	Avalie se quer mover a faixa. Uma notificação vai te avisar.
⬜	Preço saiu da faixa	Posição parou de gerar rendimento	Ajuste a faixa ou retire a liquidez. Sem urgência — capital não está em risco.

Copy de rodapé: "Saída da faixa não é perda. Quando o preço sai, sua posição fica parada — sem rendimento, mas com o capital preservado. Você pode agir quando quiser."
Link pedagógico: "Entender gestão de posição V3 →" — abre painel de ajuda lateral (não nova aba).

Para faixa total:

Seção muito mais curta: "Posição ativa em todos os preços. Sem necessidade de ajuste de faixa. Rendimento acumula automaticamente."

Preferência de notificação (apenas no Estado B — ação de valor imediato)
- Card compacto abaixo do onboarding de gestão:
- "Quer ser avisado quando o preço se aproximar da borda da faixa?"
- Toggle: "Ativar alertas de faixa" — desligado por default (opt-in, não opt-out).
- Quando ativado: input de e-mail ou integração com Telegram/Push (método configurado em Preferências). Sub-copy: "Você pode configurar outros canais de notificação em Preferências."
- Aviso de limite de alertas se gratuito tiver threshold: "Alertas gratuitos: até 5 por mês. Sem limite no plano Pro." (somente se aplicável — não exibir se não houver modelo de planos).
CTAs de navegação (sticky bar em mobile, inline em desktop)
- CTA primário: "Ver minha posição" — navega para a tela de detalhe da posição (pools-02 com contexto desta posição específica + sub-tab "Minhas posições" ativa).
- CTA secundário: "Ver o pool" (outline) — navega para pools-02 do pool geral (catálogo de pares, não a posição individual).
- Link terciário: "Adicionar mais liquidez" — reinicia o fluxo a partir de pools-03 com par pré-preenchido.
- Em mobile: botão primário full-width na sticky bar; secundário e terciário como links abaixo.

Cosmético (polish, vai depois do estrutural)

Animação de confirmação: quando a tx confirma enquanto o usuário ainda está na tela (transição de Estado A → Estado B), a transição é animada (o ícone de loading vira checkmark com micro-animação). Duração: ~800ms. Não replay na próxima abertura.
Compartilhamento discreto: ícone de compartilhamento no card de identidade da posição — copia URL da posição (parâmetros: par, protocolo, faixa, rede) sem incluir valores de aporte (privacidade). Label: "Copiar link desta posição" — nunca "Compartilhar" genérico.

Regras de negócio

Esta tela existe em 3 estados (pendente / confirmado / falhou). O estado é determinado pela hash de transação recebida de pools-05. Se o usuário abrir a URL desta tela sem hash de transação (acesso direto), redireciona para pools-01.
Polling de status: enquanto no Estado A (pendente), polling do status da tx a cada 5s via RPC ou event listener. Quando confirmada, transição automática para Estado B com animação. Quando revertida, transição para Estado C.
Timeout de confirmação (> 20 minutos sem confirmação): aviso: "Sua transação está demorando mais que o esperado. Isso pode acontecer quando o gas está baixo. Você pode acelerá-la na sua carteira ou aguardar." CTAs: "Como acelerar" (link de ajuda) + **"Aguardar"*.
Heurística de "primeira posição": se o endereço conectado não tem histórico de LP on-chain, o bloco "O que acontece agora" aparece expandido por default. Se já tem histórico, aparece colapsado. Inferência simples (query de NFTs de LP do endereço).
Notificação de faixa: apenas para faixas não-totais (±10%, ±5%, personalizadas). Para faixa total: aviso de faixa não faz sentido (posição não tem expiração).
Navegação pós-sucesso: "Ver minha posição" deve navegar para a detail view da posição específica (identificada pelo NFT ID gerado), não para o catálogo geral de pools. A sub-tab "Minhas posições" em pools-01 deve destacar a nova posição por 5s após o retorno (herdado do estado de sucesso em pools-01).
Back-navigation nesta tela: botão de voltar do browser (browser back) leva para pools-01, não para pools-05 (que já submeteu a transação — não faz sentido voltar para revisão de uma tx que já foi enviada). Histórico de navegação limpo nesta tela.
Caso de falha com diagnóstico: mensagem de erro específica por tipo de revert:
- Slippage excedido → "A variação de preço durante a transação foi maior que a tolerância definida. Tente de novo com tolerância maior em Configurações avançadas."
- Gas insuficiente → "Gas insuficiente para executar. Aumente o gas em Configurações avançadas e tente de novo."
- Allowance insuficiente → "Permissão de token expirou ou foi insuficiente. As aprovações serão solicitadas novamente."
- Erro genérico de contrato → "A transação foi revertida pelo contrato. Isso pode ter ocorrido por mudança de preço abrupta. Tente de novo."
- Em todos os casos: confirmar "Nenhum token saiu da sua carteira."

Estados não-triviais

Estado	Comportamento
Pendente — normal	Estado A completo: loading animado, estimativa de tempo, hash + link explorer, banner "pode fechar".
Pendente — lento (> 5 min)	Aviso de timeout: "Transação demorando mais que o esperado. Pode ser acelerada na sua carteira." Links: "Como acelerar" (ajuda) + "Aguardar".
Pendente — usuário fechou a tela e voltou	Retoma no estado atual da tx: se ainda pendente, mostra Estado A; se confirmada, mostra Estado B; se falhou, Estado C. URL da tela inclui hash — estado é recuperável.
Confirmada — primeiro LP	Estado B + bloco "O que acontece agora" expandido por default. Toggle de notificação visível.
Confirmada — LP recorrente	Estado B + bloco "O que acontece agora" colapsado por default. Toggle de notificação visível.
Falhou — slippage excedido	Estado C. Diagnóstico: "A variação de preço durante a transação foi maior que a tolerância definida." CTA primário: "Tentar de novo com tolerância maior" (abre pools-05 com sugestão de aumentar tolerância).
Falhou — gas insuficiente	Estado C. Diagnóstico: "Gas insuficiente para executar." CTA primário: "Tentar de novo com gas maior" (abre pools-05 com configurações avançadas abertas).
Falhou — allowance insuficiente	Estado C. Diagnóstico: "Permissão de token expirou ou foi insuficiente." CTA primário: "Tentar de novo" (abre pools-05; o fluxo de aprovação é reiniciado).
Falhou — revert genérico	Estado C. Diagnóstico: "A transação foi revertida pelo contrato. Tente de novo." + link "Ver detalhes do erro" para log técnico.
Acesso direto sem hash	Redireciona para pools-01 com banner: "Sessão expirada. Comece um novo aporte."
Wallet desconectada durante pendência	Banner discreto: "Carteira desconectada. Sua transação continua sendo processada independentemente." — polling não depende de wallet para monitorar.
Sem conexão com explorer (link para Etherscan falha)	Link "Ver no Etherscan ↗" fica cinza com tooltip: "Explorer temporariamente indisponível." Hash ainda é exibido e copiável.

Microcopy crítico (PT-BR)

Elemento	Texto
Card identidade — par	ETH / USDC · V3 · 0,05%
Card identidade — faixa	R$ 16.689 – R$ 20.397 (±10%)
Card identidade — valores	1,17 ETH + R$ 21.695 USDC · Total: ≈ R$ 43.390
Estado A — Título	Transação enviada
Estado A — sub-copy	Sua posição está sendo confirmada na blockchain. Isso geralmente leva de 15 segundos a 3 minutos.
Link explorer	Ver no Etherscan ↗
Banner "pode fechar"	Você pode fechar esta tela com segurança. Sua posição aparecerá em 'Minhas posições' assim que confirmada.
Progresso estimado	Estimativa: ~45 segundos
Estado B — Título	Posição criada com sucesso!
Estado B — sub-copy	Sua liquidez já está ativa no pool ETH/USDC. Você começa a ganhar rendimento com cada troca feita neste par.
Estado C — Título	Transação não concluída
Estado C — nenhum fundo movido	Nenhum token saiu da sua carteira.
CTA tentar de novo	Tentar de novo
Link detalhes do erro	Ver detalhes do erro
Onboarding — título	Sua posição precisa de atenção às vezes
Item ativo (🟢) — situação	Preço dentro da faixa
Item ativo — o que acontece	Posição ativa — gerando rendimento a cada troca
Item ativo — o que fazer	Nada. O rendimento acumula automaticamente.
Item próximo do limite (🟡) — o que fazer	Avalie se quer mover a faixa. Uma notificação vai te avisar.
Item fora da faixa (⬜) — o que acontece	Posição parou de gerar rendimento
Item fora da faixa — o que fazer	Ajuste a faixa ou retire a liquidez. Sem urgência — capital não está em risco.
Rodapé onboarding	Saída da faixa não é perda. Quando o preço sai, sua posição fica parada — sem rendimento, mas com o capital preservado. Você pode agir quando quiser.
Link ajuda V3	Entender gestão de posição V3 →
Onboarding faixa total	Posição ativa em todos os preços. Sem necessidade de ajuste de faixa. Rendimento acumula automaticamente.
Notificação — pergunta	Quer ser avisado quando o preço se aproximar da borda da faixa?
Toggle notificação	Ativar alertas de faixa
Sub-copy notificação	Você pode configurar outros canais de notificação em Preferências.
Timeout tx lenta	Sua transação está demorando mais que o esperado. Isso pode acontecer quando o gas está baixo. Você pode acelerá-la na sua carteira ou aguardar.
Link acelerar tx	Como acelerar
CTA primário	Ver minha posição
CTA secundário	Ver o pool
Link adicionar mais	Adicionar mais liquidez
Slippage excedido	A variação de preço durante a transação foi maior que a tolerância definida. Tente de novo com tolerância maior em Configurações avançadas.
Gas insuficiente	Gas insuficiente para executar. Aumente o gas em Configurações avançadas e tente de novo.
Allowance insuficiente	Permissão de token expirou ou foi insuficiente. As aprovações serão solicitadas novamente.
Revert genérico	A transação foi revertida pelo contrato. Isso pode ter ocorrido por mudança de preço abrupta. Tente de novo.
Compartilhamento	Copiar link desta posição
Explorer indisponível	Explorer temporariamente indisponível.

Rastreabilidade obrigatória

🟢 Herdado

Sticky de identidade: card de par/protocolo/faixa/valores sempre visível nos três estados de transação — usuário não perde contexto de "o que eu criei" mesmo enquanto a tx está pendente. Fonte: [uniswap/_consolidado/visualizar-pool.md § Insight — Sticky de identidade + CTAs em mobile].
Hash de transação com link para explorer externo: dado on-chain canônico dentro do produto, não só link genérico. Fonte: [uniswap/_consolidado/visualizar-pool.md § Insight — Dados on-chain inline sem desvio para explorer externo].
Banner "pode fechar" durante pendência: usuário não precisa permanecer na tela enquanto aguarda confirmação — remove ansiedade de "preciso ficar aqui?". Fonte: [pancake-final § Pilar 2 — CTA dinâmico + Default contextual] (informação proativa sobre o que o usuário pode fazer, não só o que o sistema está fazendo).
Diagnóstico específico por tipo de falha (nunca mensagem genérica de erro): cada tipo de revert tem sub-copy contextual + CTA de recovery específico. Fonte: [pancake-final § Insight — Transparência proativa antes do CTA] + [uniswap-final § Insight — Estados como instrução acionável].
Navegação pós-sucesso para "Minhas posições" com posição nova destacada. Fonte: [proposta/pools/pools-01.md § Estados — Sucesso — usuário criou primeira posição] — continuidade narrativa interna do fluxo.
Gas em R$ em toda menção de custo nesta tela. Fonte: [pancake-final § Pilar 5 — Localização BR/LatAm].
Opt-in de notificação (não opt-out): toggle de alerta desligado por default; usuário escolhe ativar. Fonte: [pancake-final § Pilar 7 — Curadoria opinionada] — produto opinionado não pressupõe que o usuário quer notificações.

🔴 Corrige

Fricção #2 — i18n parcial: todo copy desta tela em PT-BR; valores em R$ com locale correto. [pancake-final § Fricção 2 — i18n parcial].
Fricção — Affordance sem estado honesto: estado de tx pendente tem ícone animado reconhecível (não spinner genérico) + estimativa de tempo explícita — não deixa o usuário em dúvida se o sistema travou. [uniswap/_consolidado/visualizar-pool.md § Fricção — Affordance sem estado honesto].

🟡 Captura

Pilar 4 — Educação contextual pós-ação: onboarding de gestão V3 no momento de maior receptividade — o usuário acabou de criar sua primeira posição V3 e está mais receptivo do que em qualquer outro momento para aprender como gerenciá-la. A tabela "Preço dentro/próximo/fora da faixa" com "o que acontece" e "o que fazer" traduz o conceito de concentrated range de forma acionável, sem jargão. [pancake-final § Pilar 4]. Hipótese: usuário que lê "saída da faixa não é perda de capital — é pausa no rendimento" antes de fechar a tela não vai abrir ticket de suporte dizendo "perdi meu dinheiro" quando a posição expirar. Diferenciador direto vs Uniswap e Pancake, que mostram apenas "Transaction Submitted" sem qualquer contexto de gestão.
Pilar 6 — Risk signaling sistêmico: alertas de faixa como infraestrutura de proteção ativa — toggle opt-in para notificação quando o preço se aproxima do limite da faixa. [pancake-final § Pilar 6]. Hipótese: LP que recebe notificação de faixa em risco tem mais chance de agir a tempo (ajustar faixa ou retirar) do que LP que monitora manualmente — reduz capital parado em posições expiradas sem gestão.
Pilar 5 — Mobile-first: banner de "pode fechar" durante pendência elimina o comportamento de "ficar olhando para a tela esperando" — crítico em mobile onde o usuário tem custo de atenção mais alto. [pancake-final § Pilar 5]. Hipótese: usuário mobile que fecha a tela confiante de que a posição vai aparecer em "Minhas posições" tem melhor experiência que usuário que fica com o app aberto por 3 minutos aguardando.
Diagnóstico específico por tipo de falha com CTA de recovery direcionado: Uniswap e Pancake exibem hash de tx revertida sem diagnóstico. Kotai entrega causa + ação específica por tipo de erro. [uniswap/_consolidado/visualizar-pool.md § Fricção — Affordance sem estado honesto] + [pancake-final § Pilar 4]. Hipótese: usuário que lê "slippage excedido — tente de novo com tolerância maior" tenta novamente em vez de abandonar o produto.

⚪ Novo

Onboarding de gestão V3 pós-confirmação como componente estrutural da tela de sucesso. Não está documentado nos relatórios de concorrentes nem como insight herdável — é ausência identificada (concorrentes não fazem), não padrão a herdar. Justificativa: V3 é o protocolo recomendado em pools-03 para o par mais comum (ETH/USDC), mas é radicalmente mais complexo de gerir que V2. Entregar o manual de voo na tela de sucesso — quando o usuário está mais receptivo e ainda não cometeu o erro de ignorar a posição expirada — é o único momento de custo zero para essa educação. Risco: iniciante em faixa total (sem gestão necessária) vê onboarding irrelevante → mitigado pela variação de conteúdo por tipo de faixa. Evidência futura a coletar: taxa de abertura de tickets de suporte sobre "posição expirada / rendimento zero" antes e depois desta tela; e taxa de ativação do toggle de notificações.
Heurística de "primeira posição LP" para expandir/colapsar o onboarding (inferência por histórico on-chain de NFTs de LP do endereço). Não está documentado nos relatórios. Justificativa: apresentar o manual de gestão expandido para LP recorrente é condescendente e infla a tela desnecessariamente; colapsado por default para recorrente respeita a velocidade do intermediário. Risco: heurística errada (endereço com histórico de LP em outro protocolo) — fallback aceitável: sempre mostrar expandido na primeira posição na Kotai (usando histórico da Kotai, não on-chain global). Evidência futura: taxa de expansão manual do bloco por usuários com histórico vs sem histórico.
Compartilhamento de link de posição (URL com par/protocolo/faixa/rede, sem valores de aporte). Não está documentado nos relatórios. Justificativa: deep-link de posição tem valor em suporte ("me manda o link da sua posição"), em comunidades ("estou aportando em ETH/USDC ±10%") e em futura funcionalidade de "copiar estratégia de LP" (seguir posição de outro LP). Risco baixo: feature cosmética de copiar URL, não feature de produto nova. Evidência futura: frequência de uso do botão de compartilhamento.

Trade-offs e segunda ordem

Onboarding de gestão V3 adiciona conteúdo significativo à tela de sucesso. Em mobile, o usuário pode ter que scrollar para ver o CTA "Ver minha posição" — garantir que o CTA seja sticky na sticky bar independentemente do comprimento do conteúdo. Não sacrificar o CTA de navegação pelo conteúdo do onboarding.
Polling de status da transação (a cada 5s) tem custo de request por usuário. Em cenário de alta demanda, 1.000 usuários com posições pendentes = 200 requests/segundo. Mitigação: WebSocket ou event listener de contrato em vez de polling HTTP — mais eficiente, mas com custo de implementação maior. Fallback razoável: polling com backoff exponencial (5s → 10s → 30s → 60s).
Diagnóstico específico por tipo de revert exige que o frontend interprete o revert reason da transação — pode ser opaco em alguns contratos. Fallback: exibir revert genérico + link "Ver detalhes do erro" com o log bruto para o avançado. Nunca silenciar o erro.
Heurística de "primeira posição" (query de NFTs de LP on-chain) tem latência — se a query demorar > 1s, o onboarding pode aparecer colapsado por default enquanto aguarda a resposta, e expandir ao carregar. Aceitar com fade-in suave.
Toggle de notificação de alerta de faixa exige infraestrutura de monitoramento on-chain contínuo (verificar preço a cada X minutos e comparar com bounds da posição do usuário). Custo de infra recorrente real. Evidência futura: taxa de ativação do toggle calibra a prioridade de implementação do monitoramento.
i18n do onboarding de gestão V3 é conteúdo longo (3 itens com 3 campos cada). String count significativo; exige validação de comprimento em PT-BR por breakpoint (mobile ~320px de largura pode truncar célula da tabela). Testar em PT-BR antes de lançar.
Back-navigation limpando histórico (browser back vai para pools-01, não pools-05) altera o histórico de navegação do browser — técnica de navigation history management que pode confundir usuário em app SPA se não for comunicada. Mitigação: manter o botão "← Voltar" na tela redirecionando explicitamente para pools-01 com label contextual: "← Ver catálogo de pools" — sem ambiguidade de "para onde eu vou se apertar voltar".

Conflitos de pilar resolvidos

Pilar 4 (educação contextual: mostrar onboarding V3 completo) vs A2 (sobre-escopar a tela: tela de sucesso tem propósito de confirmação, não de educação): onboarding de gestão é contextual e inseparável do ato de criação de posição V3 — a gestão de range faz parte do contrato de uso de V3. Não é feature de outro fluxo, é consequência imediata do aporte. Decisão: mantém onboarding nesta tela, colapsável para recorrente. Pilar 4 vence sobre a preocupação de scope porque a educação é sobre esta tela específica, não sobre outro produto.
Pilar 7 (curadoria opinionada: mostrar o que o iniciante precisa saber) vs Pilar 5 (mobile-first: tela enxuta, sem scroll excessivo): onboarding colapsável com CTA sticky no rodapé resolve — usuário mobile que não quer ler o onboarding vê o CTA imediatamente; quem quer ler, scrolla. Pilares não conflitam quando o CTA não depende do conteúdo expandido.
Pilar 3 (defesa em camadas: alertar sobre posição expirada) vs A3 (solução pior que o problema: não bloquear o usuário com aviso obrigatório): onboarding é informação opt-in (colapsável) + notificação opt-in (toggle). Nenhum fluxo é bloqueado por warning. Pilar 3 implementado como infraestrutura de conhecimento disponível, não como barrier.

Pools — Tela 7 — Detalhe da minha posição ("Acompanhar minha posição")

Função da tela

Cockpit pessoal de uma posição LP: o usuário (foco em intermediário recorrente, com iniciante recém-criando a primeira posição como segundo perfil) quer saber "como está a minha posição?" — se está gerando rendimento (range status), quanto acumulou em taxas, qual é o resultado financeiro líquido (delta vs aporte + IL estimado) — e tomar ações de gestão. Tela radicalmente diferente de pools-02: pools-02 é o painel do pool como ativo público; esta tela é o painel de quem tem capital comprometido nele.

Ponto de entrada: "Ver minha posição" (pools-06) e "Gerenciar" (pools-01 › Minhas posições).

Componentes / elementos

Estrutural (define o paradigma da tela)

Header de identidade sticky
- Par + protocolo + fee + ID compacto: "ETH / USDC · V3 · 0,05% · #123456"
- Breadcrumb: "Ganhar rendimento › Minhas posições › ETH/USDC" — tap retorna para sub-tab "Minhas posições" em pools-01 preservando filtros.
- Badge de status de range — componente de mais alta prioridade desta tela, dinâmico e sempre visível no header:
  - 🟢 "Ativa" (verde) — preço dentro da faixa, rendimento acumulando.
  - 🟡 "Perto do limite" (âmbar) — preço dentro de 5% da borda inferior ou superior.
  - ⬜ "Fora da faixa" (cinza) — preço saiu da faixa, rendimento pausado.
  - Sem badge — posição V2/StableSwap (faixa total, range não se aplica).
Card de desempenho pessoal (componente central)
- Valor atual da posição em R$ (tokens A + B ao preço corrente do oráculo) — fonte de destaque.
- Delta desde o aporte em R$ e %: ↑ R$ 120,40 (2,3%) desde o aporte — verde quando positivo, vermelho quando negativo.
- Breakdown de tokens: quantidade atual de ETH e USDC na posição + equivalente em R$ de cada um.
- "Variação de composição estimada (IL) ⓘ" em R$ e %: valor estimado de IL até o momento. Label primário usa o eufemismo pedagógico; tooltip revela o nome técnico e explica o conceito completo.
  - Tooltip: "Quando os preços dos tokens mudam após o aporte, a composição da posição muda junto com eles — é o impermanent loss (IL). Não é uma perda realizada: só se concretiza ao retirar. Se o preço voltar ao patamar do aporte, o IL desaparece."
Mini-chart de faixa de preço (mobile-first, herdado de pools-04)
- Gráfico de preço dos últimos 7d com banda colorida sobre a faixa ativa.
- Linha vertical: "Preço atual: 1 ETH = R$ 18.543,20".
- Área sombreada mostra a faixa definida em pools-04.
- Tap-and-stick em mobile: arrastar o dedo mostra o preço do candle naquele ponto.
- Quando out-of-range: área sombreada em âmbar + preço atual fora da banda.
Card de taxas acumuladas
- Label: "Taxas prontas para coletar"
- Breakdown: 0,003 ETH + 4,20 USDC ≈ R$ 59,80
- Quando taxas > R$1,00: CTA inline primário "Coletar taxas →" (leva para pools-08).
- Quando taxas = R$0,00 ou < R$0,01: copy informativo, sem CTA.
Informações da posição (seção colapsável por default em intermediário, expandida em primeira posição)
- Faixa: R$ 16.689 – R$ 20.397 (±10%) + protocolo + fee tier
- Data de criação: 12 de abril de 2026
- Valor do aporte original: 1,17 ETH + R$ 21.695 USDC ≈ R$ 43.390
- Link: "Ver detalhes do pool ↗" — abre pools-02 em nova aba.
CTAs de gestão (sticky footer em mobile, inline em desktop)
- "Coletar taxas" — primário, ativo somente quando taxas > R$0,01. Quando zero: desabilitado com label "Nenhuma taxa para coletar ainda."
- "Adicionar mais liquidez" — secundário (outline). Leva para pools-03 com par e protocolo pré-preenchidos.
- "Remover liquidez" — terciário (link de texto). Leva para pools-09.

Cosmético (polish, vai depois do estrutural)

Timestamp de dados — rodapé discreto: "Atualizado às 11:28 · a cada 30s."
ID da posição NFT — compacto e copiável: #123456 + ícone de cópia. Link para explorer externo rotulado: "Ver no Etherscan ↗".
Link "Ajustar faixa" — visível somente quando status = "Perto do limite" ou "Fora da faixa". Leva para pools-04 com a posição pré-carregada para reposicionamento. (Implementação de reposicionamento fora do escopo desta tela; link abre pools-04 em estado de "editar posição existente".)

Regras de negócio

Herança de contexto obrigatória: esta tela recebe positionId da URL. Se acessada sem ID, redireciona para pools-01 sub-tab "Minhas posições" com mensagem: "Selecione uma posição para gerenciar."
Range status é calculado em tempo real (polling 30s ou WebSocket): preço atual do oráculo vs [tickLower, tickUpper] da posição. Threshold de "Perto do limite" = preço dentro de 5% da borda mais próxima. Threshold configurável como preferência de notificação (ativado em pools-06).
IL estimado: IL = valor_atual_da_posição - valor_hipotético_hold. Requer o preço dos dois tokens no momento do aporte (obtido do evento on-chain de mint). Se evento não disponível (posição migrada de outra versão ou importada), exibir "IL não disponível para esta posição" — nunca tentar estimar sem dado de referência.
Delta desde o aporte: delta = valor_atual - valor_aportado. Inclui IL + taxas acumuladas + variação de preço dos tokens. Tooltip explica os três componentes.
Posição V2/StableSwap: badge de range ausente; mini-chart sem banda; seção de faixa exibe "Liquidez distribuída em todos os preços — sem faixa ativa."
Posição out-of-range: aviso inline expandido por default na primeira visita; colapsável nas visitas subsequentes. CTA "Coletar taxas" ainda disponível (taxas acumuladas antes de sair do range continuam disponíveis); "Adicionar mais" disponível; "Remover liquidez" disponível.
Posição encerrada (liquidez já removida): header mostra "Posição encerrada". Card de desempenho em modo read-only com valor de saída. CTAs de gestão ocultos. CTA único: "Ver catálogo de pools".
Polling de oráculo: quando oráculo > 30s sem atualização, valores em cinza com asterisco + "Preço pode estar desatualizado."

Estados não-triviais

Estado	Comportamento
Loading inicial	Skeleton em header, card de desempenho, mini-chart e taxas. Label: "Carregando sua posição ETH/USDC…"
Posição ativa, in-range	Badge 🟢 "Ativa". Card de taxas visível se taxas > R$0,01.
Posição perto do limite	Badge 🟡 "Perto do limite" + aviso inline colapsável: "O preço está a X% da borda inferior da faixa. Fora dela, o rendimento pausa." + link "Ajustar faixa".
Posição out-of-range	Badge ⬜ "Fora da faixa" + card de aviso expandido (não colapsável na primeira visita): "Sua posição parou de gerar rendimento. Capital preservado — sem urgência para agir." + CTAs inline: "Ajustar faixa" e "Remover liquidez".
Posição V2 / faixa total	Sem badge de range. Mini-chart sem banda. Seção de faixa com copy explicativo.
Sem taxas acumuladas	Card de taxas com "R$ 0,00 · As taxas acumulam conforme o pool é usado." CTA "Coletar taxas" desabilitado.
IL muito negativo (IL > 20% do aporte)	Tooltip de IL expandido automaticamente + link pedagógico: "Entender por que isso acontece →". Não bloqueia nenhuma ação.
Erro de RPC / dados	Banner não bloqueante: "Dados desatualizados há X minutos. Tentando reconectar…" + CTA "Tentar agora".
Wallet desconectada	Banner bloqueante: "Carteira desconectada. Reconecte para ver sua posição." + CTA "Conectar carteira".
Rede errada	Banner: "Você está na rede [X]. Esta posição existe em [Y]. Mude para continuar." + CTA "Mudar para [Y]". CTAs de gestão desabilitados com label contextual.
Posição encerrada	Card read-only com valor de saída. Mensagem: "Esta posição foi encerrada em [data]." CTAs de gestão ocultos.
Primeiro acesso pós-criação (vindo de pools-06)	Seção "Informações da posição" expandida por default. Badge de onboarding: "Posição criada há X minutos — rendimento começa a acumular com cada troca."

Microcopy crítico (PT-BR)

Elemento	Texto
Breadcrumb	Ganhar rendimento › Minhas posições › ETH/USDC
Título implícito da posição	ETH / USDC · V3 · 0,05% · #123456
Badge ativo	✅ Ativa
Badge perto do limite	⚠ Perto do limite
Badge fora da faixa	⬜ Fora da faixa
Label valor atual	Valor atual da posição
Delta positivo	↑ R$ 120,40 (2,3%) desde o aporte
Delta negativo	↓ R$ 85,20 (1,9%) desde o aporte
Label IL	Variação de composição estimada (IL) ⓘ
Tooltip IL	Quando os preços dos tokens mudam após o aporte, a composição da posição muda junto. Isso é o impermanent loss (IL). Não é uma perda realizada — só se concretiza se você retirar agora. Se o preço voltar ao patamar do aporte, o IL desaparece.
Tooltip delta	Inclui três componentes: taxas acumuladas, variação de preço dos tokens, e variação de composição (IL).
Label taxas	Taxas prontas para coletar
Valor taxas	0,003 ETH + 4,20 USDC ≈ R$ 59,80
Sem taxas	R$ 0,00 · As taxas acumulam conforme o pool é usado.
CTA coletar taxas (ativo)	Coletar taxas →
CTA coletar taxas (inativo)	Nenhuma taxa para coletar ainda.
CTA adicionar mais	Adicionar mais liquidez
CTA remover	Remover liquidez
Aviso out-of-range	Sua posição parou de gerar rendimento. Capital preservado — sem urgência para agir.
Link ajustar faixa	Ajustar faixa
Faixa V2	Liquidez distribuída em todos os preços — sem faixa ativa.
Loading	Carregando sua posição ETH/USDC…
Dados desatualizados	Dados desatualizados há X minutos. Tentando reconectar…
Wallet desconectada	Carteira desconectada. Reconecte para ver sua posição.
Rede errada	Você está na rede [X]. Esta posição existe em [Y]. Mude para continuar.
CTA mudar rede	Mudar para [Y]
Posição encerrada	Esta posição foi encerrada em [data].
Onboarding pós-criação	Posição criada há X minutos — rendimento começa a acumular com cada troca.

Rastreabilidade obrigatória

🟢 Herdado

Sticky de identidade com par + protocolo + ID da posição — template resistente a casos bom e ruim sem tratamento gráfico diferente. Fonte: [uniswap posicao-populada-01 § Insight 1 — Pool detail bem populado vira argumento de venda]
Chip-strip / badge de saúde persistente durante toda a tela (evolução do chip-strip de pools-02, pools-04, pools-05). Fonte: [uniswap/_consolidado/visualizar-pool.md § Oportunidade — Contexto persistente no ato de operar]
Tap-and-stick no mini-chart em mobile. Fonte: [pancake-final § Pilar 5 — Mobile-first interaction]
Gas em R$, nunca em GWEI. Fonte: [pancake-final § Pilar 5 — Localização BR/LatAm como infraestrutura]
CTA desabilitado com label contextual ("Nenhuma taxa para coletar ainda."). Fonte: [pancake-final § Pilar 2 — CTA dinâmico] + [uniswap-final § Insight — Estados como instrução acionável]
Link de explorer externo rotulado ("Ver no Etherscan ↗"), não endereço cru. Fonte: [uniswap/_consolidado/visualizar-pool.md § Insight — Dados on-chain inline]
Aviso out-of-range não bloqueia nenhuma ação — soberania do usuário. Fonte: [uniswap-final § Hierarquia de risco preservada por defaults pró-segurança]
Seção "Informações da posição" colapsável — progressive disclosure; intermediário não vê dados já conhecidos. Fonte: [uniswap-final § Insight — Progressive disclosure como padrão arquitetural]

🔴 Corrige

APR de pool como number único sem contexto de range → Não exibimos APR projetado; exibimos taxas reais acumuladas em tokens e R$, e delta real desde o aporte. [uniswap posicao-populada-01 § Fricção 1 — APR 47% em fonte gigante é o APR médio da pool, não o APR do range escolhido]
Ausência de sinalização de range status em V3 → Badge de status (Ativa/Perto do limite/Fora da faixa) como componente de primeiro nível no header sticky. Sinalizar de imediato se a posição está gerando rendimento ou não é risk signaling de primeiro nível — sem o badge o usuário precisa cruzar preço corrente com memória do range para descobrir isso. [pancake-final § Pilar 6 — Risk signaling sistêmico] + [uniswap/_consolidado/visualizar-pool.md § Oportunidade — Contexto persistente no ato de operar]
"Perda impermanente" como label primário que assusta antes do contexto → Label "Variação de composição estimada (IL) ⓘ" com tooltip completo. [pancake-final § Fricção 1 — Léxico de protocolo e infraestrutura como vocabulário primário de UI]
i18n parcial → Todo copy em PT-BR; R$ com locale; termos técnicos (IL, V3) como secondary labels ou tooltips. [pancake-final § Fricção 2 — i18n parcial e inconsistente]
Empty state de posição vazio sem instrução → Todos os estados (out-of-range, wallet desconectada, rede errada) têm copy contextual + CTA acionável. [uniswap-final § Insight — Estados como instrução acionável, não decoração]

🟡 Captura

Pilar 4 — Educação contextual no ponto de decisão: IL exibido como "Variação de composição estimada ⓘ" com tooltip pedagógico completo — não como "Perda impermanente" que activa alarme antes da leitura. [pancake-final § Pilar 4 — Educação contextual]. Hipótese: label menos alarmante aumenta taxa de usuários que leem o dado (vs fecham a tela), calibrando expectativa real.
Pilar 6 — Risk signaling sistêmico: badge de range como risk signal de primeiro nível no header — o primeiro elemento que o usuário vê ao entrar na tela comunica imediatamente se a posição está ativa ou não. [pancake-final § Pilar 6 — Risk signaling sistêmico]. Hipótese: usuário que vê "Fora da faixa" no badge antes de qualquer número toma ação de gestão mais rápido que usuário que precisa interpretar um gráfico para descobrir isso.
Pilar 4 — Taxas reais acumuladas em vez de APR projetado: card de taxas em tokens e R$ é a métrica que traduz LP em ação imediata ("devo coletar agora?"). [uniswap/_consolidado/pools.md § Oportunidade — Sistema pedagógico de métricas DeFi]. Hipótese: "R$ 59,80 prontas para coletar" converte em ação; "APR 12,4%" não.
Pilar 5 — Mobile-first: badge de status no header sticky garante que o dado mais importante (posição ativa ou não) fica visível mesmo quando o usuário scrolla o conteúdo. [pancake-final § Pilar 5 — Mobile-first interaction].

⚪ Novo

Label "Variação de composição estimada (IL)" como label primário para impermanent loss. Não documentado nos relatórios como padrão de nenhum concorrente — todos usam "Impermanent Loss" ou "IL" diretamente. Justificativa: o label técnico correto ativa modelo mental de "perda" antes do contexto; usuário que vê "perda" pode remover liquidez desnecessariamente (ação irreversível). Eufemismo pedagógico acompanhado de tooltip com o nome técnico não suprime o conceito — apenas introduz em dois passos (label → tooltip). Risco: usuário avançado pode perceber como desonestidade. Mitigação: tooltip usa "impermanent loss (IL)" explicitamente. Evidência futura: taxa de abertura do tooltip de IL em versão com label técnico vs eufemístico.
Delta desde o aporte em R$ e % como métrica primária de P&L da posição. Não documentado nos relatórios como feature de position detail. Justificativa: o modelo mental do usuário iniciante é "quanto coloquei vs quanto tenho agora" — a métrica que responde isso é o delta total, não APR anualizado. Risco: delta inclui variação de preço dos tokens (exógena à decisão de LP) + IL + taxas — pode ser confundido com "resultado da decisão de ser LP". Mitigação: tooltip explicando os três componentes. Evidência futura: taxa de usuários que abrem o tooltip do delta.
Threshold de 5% para badge "Perto do limite" — valor quantitativo sem precedente documentado nos relatórios. Justificativa: 5% da borda do range é distância suficiente para que o usuário possa agir antes de sair do range (ajustar faixa ou executar coleta preventiva), sem ser tão ampla que o sinal vire ruído crônico. Risco: threshold fixo pode ser inadequado para pares de alta volatilidade (onde 5% é percorrido em horas) vs. pares estáveis. Evidência futura: correlação entre disparo do badge "Perto do limite" e taxa de saída efetiva de range em <24h — recalibrar threshold por volatilidade histórica do par se o sinal gerar muitos falsos-positivos.

Trade-offs e segunda ordem

IL estimado exige timestamp de aporte (preço dos tokens no momento do mint, obtido do evento on-chain). Se o evento não estiver indexado no subgraph ou a posição for importada de outra versão, cálculo falha silenciosamente. Fallback obrigatório: "IL não disponível para esta posição" — nunca estimativa com dado incorreto.
Badge de status de range em polling 30s implica WebSocket ou polling HTTP. 1.000 usuários com posições abertas = ~2.000 requests/minuto. Mitigação: WebSocket de evento de swap por pool (mais eficiente que HTTP polling), com fallback para polling com backoff exponencial.
"Variação de composição estimada" exige consistência de linguagem em todo o produto — se pools-02 usa "IL" e esta tela usa "Variação de composição", o usuário que busca "IL" não encontra o conceito na sua tela mais relevante. Decisão sistêmica necessária antes da implementação.
Mini-chart herdado de pools-04 adiciona ~200px de altura na tela antes das CTAs — em mobile pode empurrar "Coletar taxas" para fora da viewport sem sticky bar. Garantir que sticky footer está ativo e visível independentemente do tamanho do conteúdo acima.
i18n desta tela tem strings com números variáveis em múltiplos formatos (R$, tokens, %, datas). Intl.NumberFormat com locale pt-BR em todo cálculo de display — custo de implementação real em frontend.

Conflitos de pilar resolvidos

Pilar 4 (educação contextual: mostrar IL com contexto pedagógico completo) vs Pilar 5 (mobile-first: tela enxuta, sem scroll excessivo). Resolvido por: tooltip on-demand para o contexto pedagógico completo de IL; label primário compacto ("Variação de composição estimada ⓘ") não infla a tela. Usuário mobile que não quer ler o tooltip não é penalizado por scroll.
Pilar 6 (risk signaling: badge de out-of-range como alerta proeminente) vs A3 (armadilha: solução pior que o problema — paternalismo). Resolvido por: aviso expandido por default apenas na primeira visita em out-of-range; nas visitas subsequentes é colapsável; nenhuma ação é bloqueada. Badge informa; não impede.

Pools — Tela 12 — Stake de token único — formulário e confirmação

Função da tela

Tela de ação do segmento de stake: o usuário (foco em iniciante conservador que escolheu stake exatamente para evitar a complexidade de LP) decide quanto depositar, vê o rendimento estimado desdobrado em visão mensal e anual antes do commit, confirma os termos de lockup, e assina a transação. Mais simples que o fluxo LP (sem stepper, sem seleção de faixa, sem IL) — toda a decisão cabe em uma tela.

Ponto de entrada: CTA "Ver e depositar →" de pools-11, com pool pré-carregado.

Componentes / elementos

Estrutural (define o paradigma da tela)

Header de identidade do pool (sticky)
- Token com ícone + nome: "USDC"
- Breadcrumb: "Ganhar rendimento › Stake de token único › USDC"
- Sub-info contextual inline (3 chips no header): Rendimento est. 4,2% · Taxas: 3,8% · Incentivos: 0,4% · Sem prazo mínimo · Recompensa em USDC.
- Todos os dados do header derivam do mesmo snapshot que alimentou pools-11 — sem divergência intra-tela.
Input de quantidade (componente central — a decisão primária)
- Label: "Quanto você quer depositar?"
- Campo de input numérico com seletor de token ao lado (token é pré-definido, mas o ícone confirma identidade).
- Linha de saldo: "Disponível: 1.234,56 USDC ≈ R$ 1.234,56"
- Chips de atalho de quantidade: 25% | 50% | 75% | 100% — tap-targets de 44px mínimo. Calculam o valor em função do saldo disponível.
- Equivalente em R$ ao lado do input: "≈ R$ 1.234,56" — atualiza conforme o usuário digita.
- Auto-flip de magnitude: quando valor > R$ 10.000, exibe o R$ como label primário e o token como secondary (ex: "R$ 12.345,00 em USDC" em vez de "12.345,00 USDC ≈ R$ 12.345"). Segue padrão de auto-flip do consolidado Pancake.
Card de resultado estimado (atualiza em tempo real conforme o input muda)
- Título: "Resultado estimado"
- Por mês: "≈ R$ 4,32 (0,35% em 30 dias)" — fonte maior, posição de destaque.
- Por ano: "≈ R$ 51,84 (4,2% ao ano)" — fonte secundária, linha abaixo.
- Linha de decomposição: "Estimativa: taxas 3,8% + incentivos 0,4% · base: 7 dias de atividade."
- Nota de variabilidade: "Pode variar com o volume do pool e com o preço do token de recompensa."
- Quando token de recompensa ≠ token depositado: linha adicional: "Recompensa em [token] — o valor em R$ depende do preço de [token] no momento da coleta."
- Atualiza com debounce de 500ms — não atualiza a cada tecla, mas acompanha de perto.
Card de termos do stake (educação no ponto de commit — Pilar 4)
- Título: "Condições deste stake"
- Linhas estruturadas:
  - Prazo mínimo: Sem prazo mínimo (ou o prazo específico com badge âmbar se lockup aplicável).
  - Recompensa em: USDC (ícone do token + nome).
  - Penalidade por saque antecipado: Nenhuma (ou a penalidade específica se aplicável).
  - Aprovação de token: Apenas o valor deste depósito.
- Quando lockup existe: aviso inline em âmbar (não bloqueante): "Atenção: retirar antes de [X] dias resulta em perda dos incentivos acumulados. As taxas coletadas são preservadas."
- Link: "Ver contrato do pool →" — abre endereço do contrato no explorer externo (link rotulado, nunca endereço cru na UI).
Estimativa de gas
- Linha simples: "Gas estimado: ≈ R$ 2,80" — nunca em GWEI.
- Timestamp: "Estimativa às 11:28 · atualiza a cada 30s."
- Gas excepcionalmente alto (> 20% do valor do rendimento mensal estimado): badge âmbar + "Gas elevado em relação ao rendimento esperado. Verifique se vale a pena depositar agora."
Fluxo de aprovação de token (inline, quando necessária — mesmo padrão de pools-05 Etapa A)
- Card de aprovação compacto: "Passo 1 de 2: Permitir que o protocolo use seu USDC."
- Sub-copy: "Você vai assinar uma aprovação na sua carteira. Esta ação não move USDC — apenas concede permissão ao contrato."
- CTA: "Aprovar USDC" (outline, não preenchido — é pré-requisito, não a ação final).
- Quando já aprovado: ✓ "USDC aprovado." compacto em verde.
- Verificar allowance existente antes de exibir — se já aprovado pelo valor necessário, etapa não aparece.
CTA de confirmação (sticky rodapé em mobile, inline em desktop)
- "Confirmar depósito" — primário, ativo quando aprovações concluídas e valor > 0.
- Quando input = 0: desabilitado com label: "Insira um valor para continuar."
- Quando valor > saldo: desabilitado com label: "Saldo insuficiente de USDC."
- Quando aprovação pendente: "Conclua a aprovação acima para continuar."
- Quando aguardando assinatura: "Aguardando sua assinatura na carteira…"

Cosmético (polish, vai depois do estrutural)

Link "O que é rendimento de stake?" — link pedagógico discreto abaixo do card de termos. Abre bottom sheet com 3 linhas: de onde vem o rendimento, diferença de LP, quando faz sentido coletar vs acumular.
Link "← Voltar para catálogo de stakes" — retorna para pools-11 sem nenhuma ação on-chain.
Configurações avançadas ▾ (colapsado) — apenas deadline da transação. Sem slippage para stake de token único (depósito direto sem swap AMM). Se o protocolo for baseado em AMM interno: slippage aparece aqui.

Regras de negócio

Herança de contexto obrigatória: recebe poolId da URL (vindo de pools-11). Sem contexto, redireciona para pools-11.
Aprovação por valor exato como default (não aprovação infinita) — mesmo princípio de pools-05. Aprovação infinita disponível em Configurações avançadas com aviso: "Aprovação infinita concede acesso permanente ao contrato para este token."
Resultado estimado é calculado com base no APR da semana anterior aplicado ao valor do input. Não é projeção futura — é estimativa backward-looking. Nota de variabilidade obrigatória.
Gas > 20% do rendimento mensal estimado: aviso âmbar. Threshold relativo ao rendimento (não absoluto) — R$ 3 de gas pode ser aceitável para depósito de R$ 5.000 (rendimento mensal R$ 17,50) mas não para depósito de R$ 50 (rendimento mensal R$ 0,18). Mesmo padrão relativo de pools-08.
Quando token de recompensa ≠ token depositado: linha adicional obrigatória no card de resultado: "Recompensa em [token] — o valor em R$ depende do preço de [token] no momento da coleta." Não pode aparecer apenas como tooltip — é informação de primeiro nível para quem escolheu "Rendimento ampliado" em pools-11.
Timestamp de preço: resultado estimado e gas derivam do mesmo snapshot. Timestamp visível. Se snapshot > 60s: banner discreto: "Estimativas podem estar desatualizadas. Atualizando…"
Estado de sucesso inline (dentro desta mesma tela, não navega para nova tela): diferente de LP (que tem pools-06 dedicado com onboarding V3), o stake é operacionalmente mais simples — sucesso é confirmado inline com CTA "Ver meu stake" que leva para a sub-tab "Meus stakes" em pools-11.
Falha: diagnóstico específico por tipo (gas insuficiente, allowance, revert genérico) — mesmo padrão de pools-06.

Estados não-triviais

Estado	Comportamento
Loading inicial	Skeleton no card de resultado estimado + card de termos + estimativa de gas. Label: "Carregando dados do pool USDC…"
Input vazio	CTA desabilitado: "Insira um valor para continuar." Card de resultado mostra placeholder: "Digite um valor para ver o rendimento estimado."
Input preenchido — válido	Card de resultado atualiza com rendimento por mês e por ano. CTA ativo (se aprovação ok).
Valor > saldo	Input em âmbar. CTA desabilitado: "Saldo insuficiente de USDC." Linha de saldo em âmbar.
Gas alto (> 20% do rendimento mensal)	Badge âmbar: "Gas elevado em relação ao rendimento esperado. Verifique se vale a pena depositar agora." CTA disponível — soberania preservada.
Aprovação necessária	Card de aprovação inline aparece acima do CTA. CTA mostra: "Conclua a aprovação acima para continuar."
Aprovação assinada — aguardando confirmação on-chain	Card de aprovação com spinner + "Confirmando aprovação de USDC…"
Aprovação confirmada	Card de aprovação com ✓ verde + "USDC aprovado." CTA de confirmação entra em estado ativo.
Aguardando assinatura de depósito	Spinner no CTA + "Aguardando sua assinatura na carteira…"
Tx enviada — aguardando confirmação	CTA com loading + "Transação enviada. Aguardando confirmação…" + hash compacto. Banner: "Você pode fechar esta tela. Seu stake aparecerá em 'Meus stakes' quando confirmado."
Sucesso	Estado inline (sem navegar para nova tela): ícone de confirmação + "Depósito confirmado. Rendimento começa a acumular automaticamente." CTA muda para: "Ver meu stake →" (leva para sub-tab "Meus stakes" em pools-11 com o novo stake destacado). Link secundário: "Depositar mais" (reinicia o formulário).
Pool com lockup — confirmação	Aviso âmbar no card de termos antes do CTA: "Atenção: retirar antes de [X] dias resulta em perda dos incentivos acumulados."
Falha — gas insuficiente	"Gas insuficiente para executar. Aumente a tolerância em Configurações avançadas." CTA "Ajustar gas".
Falha — allowance insuficiente	"Permissão de token expirou ou foi insuficiente. A aprovação será solicitada novamente."
Falha — revert genérico	"Transação revertida. Nenhum USDC saiu da sua carteira." + link "Ver detalhes do erro".
Rede errada	Banner bloqueante: "Você está na rede [X]. Este pool de stake existe em [Y]. Mude para continuar." CTA "Mudar para [Y]".
Wallet desconectada	Banner bloqueante: "Carteira desconectada. Reconecte para continuar." CTA "Conectar carteira".
Snapshot desatualizado (> 60s)	Banner discreto: "Estimativas podem estar desatualizadas. Atualizando…"

Microcopy crítico (PT-BR)

Elemento	Texto
Breadcrumb	Ganhar rendimento › Stake de token único › USDC
Chips header	Rendimento est. 4,2% · Taxas: 3,8% · Incentivos: 0,4% · Sem prazo mínimo · Recompensa em USDC
Label input	Quanto você quer depositar?
Linha de saldo	Disponível: 1.234,56 USDC ≈ R$ 1.234,56
Chips atalho	25% \| 50% \| 75% \| 100%
Título card resultado	Resultado estimado
Rendimento mensal	≈ R$ 4,32 (0,35% em 30 dias)
Rendimento anual	≈ R$ 51,84 (4,2% ao ano)
Linha decomposição	Estimativa: taxas 3,8% + incentivos 0,4% · base: 7 dias de atividade.
Variabilidade	Pode variar com o volume do pool e com o preço do token de recompensa.
Recompensa em outro token	Recompensa em [token] — o valor em R$ depende do preço de [token] no momento da coleta.
Placeholder do card resultado	Digite um valor para ver o rendimento estimado.
Título card termos	Condições deste stake
Prazo — sem lockup	Prazo mínimo: Sem prazo mínimo
Prazo — com lockup	Prazo mínimo: 30 dias
Recompensa — mesmo token	Recompensa em: USDC
Penalidade — sem penalidade	Penalidade por saque antecipado: Nenhuma
Penalidade — com penalidade	Penalidade por saque antecipado: Perda dos incentivos acumulados
Aprovação de token	Aprovação de token: Apenas o valor deste depósito.
Aviso lockup	Atenção: retirar antes de 30 dias resulta em perda dos incentivos acumulados. As taxas coletadas são preservadas.
Link contrato	Ver contrato do pool →
Gas estimado	Gas estimado: ≈ R$ 2,80
Timestamp gas	Estimativa às 11:28 · atualiza a cada 30s.
Gas alto	Gas elevado em relação ao rendimento esperado. Verifique se vale a pena depositar agora.
Card aprovação — título	Passo 1 de 2: Permitir que o protocolo use seu USDC.
Card aprovação — sub-copy	Você vai assinar uma aprovação na sua carteira. Esta ação não move USDC — apenas concede permissão ao contrato.
CTA aprovar	Aprovar USDC
Estado aprovado	✓ USDC aprovado.
Aprovação infinita (avançado)	Aprovação infinita concede acesso permanente ao contrato para este token. Use com cuidado.
CTA — input vazio	Insira um valor para continuar.
CTA — saldo insuficiente	Saldo insuficiente de USDC.
CTA — aprovação pendente	Conclua a aprovação acima para continuar.
CTA — ativo	Confirmar depósito
Aguardando assinatura	Aguardando sua assinatura na carteira…
Tx enviada	Transação enviada. Aguardando confirmação…
Banner pode fechar	Você pode fechar esta tela. Seu stake aparecerá em 'Meus stakes' quando confirmado.
Sucesso — título	Depósito confirmado. Rendimento começa a acumular automaticamente.
CTA pós-sucesso (primário)	Ver meu stake →
Link pós-sucesso (secundário)	Depositar mais
Gas insuficiente	Gas insuficiente para executar. Aumente a tolerância em Configurações avançadas.
Allowance insuficiente	Permissão de token expirou ou foi insuficiente. A aprovação será solicitada novamente.
Revert genérico	Transação revertida. Nenhum USDC saiu da sua carteira.
Link detalhes do erro	Ver detalhes do erro
Rede errada	Você está na rede [X]. Este pool de stake existe em [Y]. Mude para continuar.
Wallet desconectada	Carteira desconectada. Reconecte para continuar.
Snapshot desatualizado	Estimativas podem estar desatualizadas. Atualizando…

Rastreabilidade obrigatória

🟢 Herdado

Chips de atalho de quantidade 25% / 50% / 75% / 100% — atalhos de porcentagem eliminam cálculo cognitivo. Fonte: [uniswap/_consolidado/visualizar-pool.md § Insight — Presets chips em qualquer decisão financeira] + padrão interno herdado de pools-09.
Gas em R$, nunca em GWEI. Fonte: [pancake-final § Pilar 7 — Mobile-first interaction + Localização BR/LatAm como infraestrutura].
CTA desabilitado com label contextual (sem botão cinza mudo). Fonte: [pancake-final § Pilar 6 — CTA dinâmico] + [uniswap-final § Insight — Estados como instrução acionável].
Gas relativo ao valor da operação (aviso quando gas > 20% do rendimento mensal estimado) — herdado do padrão de pools-08 (aviso quando gas > 50% das taxas). Fonte: [proposta/pools/pools-08.md § Gas > 50% do valor das taxas — aviso âmbar]. Aqui adaptado: threshold de 20% do rendimento mensal (não das taxas a coletar), porque o referencial é o custo de oportunidade do depósito, não de uma coleta pontual.
Aprovação por valor exato como default (não infinita). Fonte: [pancake-final § Pilar 2 — Defesa em camadas universal] + [proposta/pools/pools-05.md § Aprovação por valor exato].
Fluxo de aprovação ERC-20 inline com sub-copy pedagógico ("esta ação não move USDC"). Fonte: [pancake-final § Pilar 2 — Defesa em camadas universal] + [proposta/pools/pools-05.md § Fluxo de aprovação de token].
Banner "pode fechar" durante tx pendente — elimina ansiedade de "preciso ficar aqui?". Fonte: [pancake-final § Pilar 6] + padrão interno herdado de pools-06, pools-08.
Diagnóstico específico por tipo de falha (gas, allowance, revert genérico). Fonte: [pancake-final § Insight — Transparência proativa antes do CTA].
Timestamp unificado de dados (resultado estimado e gas derivam do mesmo snapshot). Fonte: [uniswap/_consolidado/visualizar-pool.md § Fricção — Métricas vivas sem âncora de snapshot].
Link de contrato para explorer rotulado — nunca endereço cru na UI. Fonte: [uniswap/_consolidado/visualizar-pool.md § Insight — Dados on-chain inline].

🔴 Corrige

APR exposto sem decomposição before commit → Header chips + linha de decomposição no card de resultado sempre visíveis antes de confirmar. Fonte: [pancake/_consolidado/visualizar-farm.md § APR opaco / decomposição escondida — Fricção estrutural].
Token de recompensa não sinalizado quando diferente do depositado → Linha obrigatória no card de resultado: "Recompensa em [token] — o valor em R$ depende do preço de [token] no momento da coleta." Fonte: [pancake-final § Fricção 5 — Risk signaling ausente em pontos de decisão de alto custo financeiro].
Lockup terms invisíveis até após o commit → Card de termos com prazo, penalidade e aviso âmbar de lockup visíveis antes do CTA. Fonte: [uniswap-final § Fricção 6 — Métricas DeFi sem decomposição, janela ou comparativo].
i18n parcial → Todo copy em PT-BR; R$ com locale; token em EN apenas quando é o nome canônico do ativo. Fonte: [pancake-final § Fricção 2 — i18n parcial e inconsistente].
CTA disabled silencioso ("Criar Ordem" cinza mudo) → CTA sempre com label que explica o bloqueio ("Insira um valor para continuar" / "Saldo insuficiente de USDC"). Fonte: [pancake-final § Fricção 10 — CTA disabled silencioso sem comunicar o gap].

🟡 Captura

Pilar 4 — Resultado estimado por mês E por ano visíveis antes do commit: dois timeframes no card de resultado eliminam a conversão mental de APR anual para "quanto vou ver na prática". [pancake-final § Pilar 4 — Educação contextual + Transparência financeira] + [pancake/_consolidado/visualizar-farm.md § Oportunidade — APR decomposto visível por default]. Hipótese: iniciante que vê "≈ R$ 4,32 por mês" antes de confirmar tem uma âncora de expectativa realista — menos chance de desistir por "rendimento menor do que esperava" após o primeiro mês.
Pilar 4 — Card de termos como educação no ponto de commit: lockup, penalidade e token de recompensa explicitados na mesma tela de confirmação — o usuário não vai descobrir esses detalhes depois. [pancake-final § Pilar 4]. Hipótese: LP que lê "sem prazo mínimo — sem penalidade" antes de confirmar tem confiança de que pode sair quando quiser; LP que descobre lockup depois tende a não usar o produto novamente.
Pilar 3 — Defesa em camadas: aviso de lockup inline (âmbar, não modal bloqueante) quando prazo mínimo > 0. [pancake-final § Pilar 2 — Defesa em camadas universal]. Hipótese: usuário que lê o aviso de lockup antes de confirmar faz o cálculo de "posso travar esse capital por X dias?" antes do commit — taxa de arrependimento pós-depósito cai.
Pilar 5 — Auto-flip por magnitude: quando o valor depositado é grande (> R$ 10.000), o R$ vira label primário e o token fica como secondary. [pancake/_consolidado/visualizar-farm.md § Auto-flip de preço por magnitude] + [pancake-final § Pilar 7 — Mobile-first interaction + Localização BR/LatAm como infraestrutura]. Hipótese: usuário que opera em valores grandes pensa em R$ primeiro — a inversão elimina a conversão mental.

⚪ Novo

Resultado estimado em duas visões de tempo (por mês E por ano) como linhas distintas no card de resultado. Não documentado nos relatórios de concorrentes como padrão de formulário de stake. Justificativa: APR anual é a convenção da indústria mas não é a unidade de experiência do usuário iniciante — "4,2% ao ano" e "R$ 4,32 por mês" carregam o mesmo dado mas têm ressonâncias distintas. O usuário iniciante calibra expectativa em tempo curto (por mês); o intermediário calibra em termos de eficiência de capital (APR). Mostrar ambos elimina a conversão mental para os dois perfis sem adicionar complexidade de UI. Risco: dois números podem criar confusão de "qual devo usar?". Mitigação: visual hierarchy clara — mensal em fonte maior (posição de destaque), anual em fonte menor (linha secundária). Evidência futura: teste A/B entre exibir só APR anual vs exibir ambos — comparar taxa de depósito completado e taxa de abandono no formulário.
Gas relativo ao rendimento mensal (aviso quando gas > 20% do rendimento mensal, em vez de threshold absoluto). Não documentado como exato padrão nos relatórios — pools-08 usa gas vs taxas a coletar. Justificativa: para stake, o referencial do custo de gas é o custo de oportunidade do depósito, não uma coleta pontual. Um depósito de R$ 50 com gas de R$ 3 e rendimento mensal de R$ 0,18 é uma operação com payback de anos — o aviso relativo captura esse caso onde o absoluto não o faria. Risco: cálculo de "rendimento mensal estimado" depende do APR atual, que pode mudar no dia seguinte; o aviso pode aparecer ou sumir conforme o APR flutua. Mitigação: timestamp do APR usado no cálculo visível na nota de variabilidade. Evidência futura: taxa de abandono da tela quando aviso de gas > 20% é exibido.
Sucesso inline (sem navegar para tela separada de confirmação) em vez de pools-06 equivalente para stake. Não documentado nos relatórios como padrão distinto de LP. Justificativa: o stake de token único não tem a complexidade pós-aporte de V3 (sem range, sem gestão de faixa, sem onboarding de "o que fazer quando expirar") — uma tela dedicada de sucesso seria A2 (sobre-escopar) porque não há conteúdo suficiente para justificar a navegação extra. O sucesso inline com CTA "Ver meu stake" serve o mesmo propósito sem inflar o fluxo. Risco: se o produto evoluir para stakes com onboarding específico (ex: staking V3 concentrado), o padrão inline pode não suportar o conteúdo. Mitigação: estrutura inline colapsável — se houver conteúdo de onboarding futuro, ele pode ser adicionado como bloco expandível no mesmo estado de sucesso sem exigir nova tela. Evidência futura: taxa de uso do CTA "Ver meu stake" vs "Depositar mais" — indica se o usuário sente necessidade de confirmação adicional.

Trade-offs e segunda ordem

Card de resultado em tempo real (debounce 500ms) exige polling do APR atual a cada mudança de input. Se o APR mudar entre o carregamento da tela e a confirmação, o resultado estimado pode divergir levemente do que o usuário viu. Mitigação: timestamp visível + nota de variabilidade. Nunca silenciar a variação.
Aprovação por valor exato exige nova aprovação se o usuário quiser depositar um valor diferente do aprovado anteriormente (ex: aprovou R$ 500, agora quer R$ 600). Verificar allowance atual antes de mostrar a etapa de aprovação — se allowance ≥ valor atual, não exibir a etapa.
Aviso de lockup adiciona estado condicional ao card de termos. Em pools sem lockup (maioria dos staking simples), o card de termos fica mais limpo. Em pools com lockup, o aviso em âmbar infla levemente a tela em mobile — garantir que o CTA sticky seja visível no rodapé independentemente do tamanho do card de termos acima.
Resultado em dois timeframes exige Intl.NumberFormat com locale pt-BR para ambas as linhas — valores com casas decimais no formato R$ 4,32. Custo de implementação pontual, valor recorrente.
Sucesso inline (sem nova tela) limita o espaço para onboarding contextual. Se no futuro existirem stakes com condições especiais (ex: staking com múltiplas recompensas, staking delegado), a tela pode precisar de revisão para acomodar conteúdo de onboarding mais denso. Evitar commitments de arquitetura que impeçam essa expansão.
Token de recompensa ≠ token depositado: a linha de resultado mostra "Recompensa em [token]" com R$ calculado ao preço atual do token de recompensa. Se o preço do token de recompensa cair 50% depois do depósito, o usuário receberá a quantidade certa de tokens mas o valor em R$ pode ser bem diferente do estimado. Nunca omitir esse aviso — é o principal risco deste tipo de stake.

Pools — Tela 8 — Coletar taxas acumuladas

Função da tela

Fluxo de claim das taxas acumuladas de uma posição LP ativa: o usuário (foco em iniciante e intermediário igualmente) decide se quer receber as taxas como tokens soltos na carteira ou reinvesti-las como liquidez adicional — e confirma a transação. Ação de baixo risco (não remove a posição), mas ainda exige assinatura on-chain e gera custo de gas. Ponto de entrada: CTA "Coletar taxas →" de pools-07.

Componentes / elementos

Estrutural (define o paradigma da tela)

Header de identidade da posição (herdado de pools-07, sticky)
- Par + protocolo + fee + ID: "ETH / USDC · V3 · 0,05% · #123456"
- Breadcrumb: "Ganhar rendimento › Minhas posições › ETH/USDC › Coletar taxas"
- Badge de status de range (herdado — a posição pode estar in-range ou out-of-range durante a coleta).
Card de taxas a receber (componente principal — o que o usuário vai receber)
- Título: "Você vai receber"
- Linha 1: 0,003 ETH ≈ R$ 55,60
- Linha 2: 4,20 USDC ≈ R$ 4,20
- Linha de total: Total ≈ R$ 59,80
- Timestamp: "Calculado às 11:28 — pode variar levemente até a confirmação."

Seletor de destino das taxas (escolha única, radio implícito de dois cartões)

Opção	Label principal	Descrição	Quando disponível
Receber na carteira (default)	Receber como tokens	ETH e USDC vão direto para a sua carteira. Pode trocar ou reaplicar quando quiser.	Sempre
Reinvestir no pool	Adicionar como liquidez	Taxas são adicionadas como liquidez na mesma faixa. Aumenta a posição sem nova transação de swap.	Somente se a posição estiver in-range

"Reinvestir no pool" desabilitado quando posição está out-of-range, com label contextual: "Disponível somente quando a posição está ativa."
Seleção default: "Receber na carteira" — iniciante não deve ser empurrado para compound automaticamente sem entender a mecânica.
Sem aviso extra ao selecionar "Receber" — é a opção padrão, sem friction.
"Reinvestir" selecionado: aparece aviso pedagógico inline (não bloqueante): "Ao reinvestir, você adiciona liquidez na mesma faixa com os dois tokens. Se a faixa sair de range depois, o rendimento pausa novamente."

Estimativa de gas
- Linha simples: "Gas estimado: ≈ R$ 3,20" (nunca em GWEI).
- Timestamp do estimate: "Estimativa às 11:28 · atualiza a cada 30s."
- Gas excepcionalmente alto (> 50% do valor das taxas): badge âmbar + "Gas elevado. A taxa de rede representa mais de 50% do que você vai receber. Verifique se vale a pena coletar agora."
CTA de confirmação (sticky rodapé em mobile, inline em desktop)
- "Confirmar coleta" — primário, ativo após assinatura das aprovações necessárias.
- Quando aguardando assinatura na carteira: "Aguardando sua assinatura na carteira…" (spinner + copy, não botão bloqueado).
- Sem wallet: "Conectar carteira para continuar".

Cosmético (polish, vai depois do estrutural)

Configurações avançadas ▾ — colapsado por default: campo "Limite de gas (max fee)" para usuários que precisam ajustar manualmente. Sem campo de slippage — coleta de taxas não envolve troca de tokens. Link discreto acima do CTA de confirmação. Padrão herdado de pools-05 e pools-09.
Link "O que são taxas de LP?" — link pedagógico discreto abaixo do card, abre bottom sheet com explicação de 3 linhas: como as taxas se acumulam, por que estão em dois tokens, quando faz sentido coletar vs reinvestir.
Link "← Voltar para minha posição" — retorna para pools-07 sem iniciar transação.

Regras de negócio

Herança de contexto obrigatória: a tela recebe positionId da URL (vindo de pools-07). Se acessada diretamente sem contexto, redireciona para pools-01.
Taxas mínimas: se as taxas acumuladas forem < R$0,01 no momento da abertura desta tela, redireciona para pools-07 com mensagem: "Sem taxas suficientes para coletar no momento." — protege o usuário de pagar gas por coleta irrisória.
Gas > 50% do valor: exibe badge âmbar + copy pedagógico. Não bloqueia a ação — usuário pode ter razão para coletar mesmo assim (ex: precisa do ETH). Soberania preservada.
"Reinvestir no pool" só disponível in-range: quando a posição está out-of-range, um ou dois tokens do LP podem estar 100% de um lado (e.g., toda USDC), impossibilitando reinvestimento proporcional sem swap interno. Para simplificar o comportamento do iniciante, opção desabilitada fora do range com label explicativo.
Aprovações ERC-20: verificar allowance antes de exibir etapas de aprovação. Para coleta de taxas, geralmente não exige aprovação nova (é retirada do contrato de LP, não novo depósito). Se necessário, exibir etapa de aprovação com o mesmo padrão de pools-05 (Etapa A/B + sub-copy explicativo).
Gas estimado: recalcula a cada 30s. Se gas subir > 50% desde a abertura: badge âmbar + "Gas aumentou desde que você abriu esta tela. Estimativa atualizada."
Timestamp de taxas: taxas mostradas são snapshot do momento de abertura da tela. Podem aumentar levemente até a confirmação (transações novas no pool acumulam mais fees durante a espera). Não re-calcular em tempo real — mostrar o valor do momento + "Pode variar levemente até a confirmação."

Estados não-triviais

Estado	Comportamento
Loading	Skeleton no card de taxas + estimativa de gas. Label: "Carregando taxas da posição #123456…"
Gas excepcionalmente alto	Badge âmbar + copy: "Gas elevado. Taxa de rede representa mais de 50% do que você vai receber. Verifique se vale a pena coletar agora." CTA disponível.
Gas muito baixo	Badge âmbar: "Gas pode ser insuficiente. Transação pode não executar. Ajuste o limite de gas em Configurações avançadas ▾." Link "Configurações avançadas ▾" expande o campo de max fee inline.
Posição out-of-range	Seletor "Reinvestir" desabilitado com label contextual. Default "Receber na carteira" permanece ativo. Badge de range visible no header.
Aprovação pendente (se necessária)	Card de aprovação inline (padrão de pools-05). CTA de confirmação aguardando.
Aguardando assinatura	Spinner no CTA + "Aguardando sua assinatura na carteira…"
Transação enviada	Navega automaticamente para estado de sucesso (tela 8-B, ver abaixo).
Transação rejeitada	"Coleta cancelada. Nenhum fundo foi movido." CTA "Tentar de novo" inline.
Erro de gas insuficiente	"Gas insuficiente para executar. Aumente a tolerância em Configurações avançadas." CTA "Ajustar gas".
Taxas insuficientes	Redireciona para pools-07: "Sem taxas suficientes para coletar no momento."
Rede errada	Banner: "Você está na rede [X]. Esta posição existe em [Y]. Mude para continuar." CTA "Mudar para [Y]".
Sucesso — tokens na carteira	Toast + retorno automático para pools-07: "R$ 59,80 em taxas adicionados à sua carteira."
Sucesso — reinvestido	Toast + retorno automático para pools-07: "Taxas reinvestidas. Sua posição aumentou."

Microcopy crítico (PT-BR)

Elemento	Texto
Breadcrumb	Ganhar rendimento › Minhas posições › ETH/USDC › Coletar taxas
Título do card	Você vai receber
Linha de token A	0,003 ETH ≈ R$ 55,60
Linha de token B	4,20 USDC ≈ R$ 4,20
Total	Total ≈ R$ 59,80
Timestamp	Calculado às 11:28 — pode variar levemente até a confirmação.
Opção A — nome	Receber como tokens
Opção A — descrição	ETH e USDC vão direto para a sua carteira. Pode trocar ou reaplicar quando quiser.
Opção B — nome	Adicionar como liquidez
Opção B — descrição	Taxas são adicionadas como liquidez na mesma faixa. Aumenta a posição sem nova transação de swap.
Opção B desabilitada	Disponível somente quando a posição está ativa.
Aviso reinvest	Ao reinvestir, você adiciona liquidez na mesma faixa com os dois tokens. Se a faixa sair de range depois, o rendimento pausa novamente.
Label gas	Gas estimado: ≈ R$ 3,20
Timestamp gas	Estimativa às 11:28 · atualiza a cada 30s.
Gas alto	Gas elevado. A taxa de rede representa mais de 50% do que você vai receber. Verifique se vale a pena coletar agora.
Gas aumentou	Gas aumentou desde que você abriu esta tela. Estimativa atualizada.
CTA confirmar	Confirmar coleta
Aguardando assinatura	Aguardando sua assinatura na carteira…
Sem wallet	Conectar carteira para continuar
Tx cancelada	Coleta cancelada. Nenhum fundo foi movido.
Gas insuficiente	Gas insuficiente para executar. Aumente a tolerância em Configurações avançadas.
Sucesso — carteira	R$ 59,80 em taxas adicionados à sua carteira.
Sucesso — reinvestido	Taxas reinvestidas. Sua posição aumentou.
Rede errada	Você está na rede [X]. Esta posição existe em [Y]. Mude para continuar.
Link pedagógico	O que são taxas de LP?
Link voltar	← Voltar para minha posição

Rastreabilidade obrigatória

🟢 Herdado

Sticky de identidade da posição herdado de pools-07 — par + protocolo + badge de range sempre visíveis durante toda a tela de ação. Fonte: [uniswap posicao-populada-01 § Insight 1 — template de identidade resistente a casos bom/ruim]
Gas em R$, nunca em GWEI. Fonte: [pancake-final § Pilar 5 — Localização BR/LatAm como infraestrutura]
CTA desabilitado com label contextual: "Disponível somente quando a posição está ativa." para o reinvestimento fora do range. Fonte: [pancake-final § Pilar 2 — CTA dinâmico]
Aviso pedagógico inline (não modal) para a opção de reinvestimento. Fonte: [pancake-final § Pilar 4 — Educação contextual + Transparência financeira]
Timestamp de dados garantindo que o usuário sabe quando o cálculo foi feito. Fonte: [uniswap/_consolidado/visualizar-pool.md § Fricção — Métricas vivas sem âncora de snapshot]
Fluxo de aprovação ERC-20 inline (quando necessário): sub-copy explicando o que acontece na carteira. Fonte: [pancake-final § Pilar 3 — Defesa em camadas]
Diagnóstico específico por tipo de falha (rejeição, gas insuficiente): nunca mensagem genérica de erro. Fonte: [pancake-final § Insight — Transparência proativa antes do CTA]
Try-before-connect: formulário exibe taxas mesmo sem wallet; CTA muda para conexão. Fonte: [uniswap-final § Insight — Ação imediata sem commit nem onboarding]

🔴 Corrige

Gas exposto em GWEI sem tradução → Gas em R$ em todas as instâncias desta tela. [pancake-final § Fricção 2 — i18n parcial]
Aviso de gas alto genérico ("Gas is high") sem contexto de impacto relativo → aviso âmbar calculado como % do valor das taxas a receber ("representa mais de 50% do que você vai receber"). [uniswap-final § Fricção 6 — Métricas DeFi sem decomposição, janela ou comparativo]
i18n parcial → Todo copy em PT-BR; R$ com locale; termos técnicos (gas) como secondary. [pancake-final § Fricção 2]

🟡 Captura

Pilar 3 — Defesa em camadas sem paternalismo: aviso de gas alto não bloqueia a ação — informa o impacto relativo (% do valor das taxas) e deixa o usuário decidir. [pancake-final § Pilar 3]. Hipótese: usuário que vê "gas representa 50% do que você vai receber" posterga a coleta para momento de gas mais baixo — economia real de custo sem bloqueio de produto.
Pilar 7 — Curadoria opinionada: default "Receber na carteira" em vez de "Reinvestir" — iniciante não é empurrado para compound automático sem entender a mecânica. [pancake-final § Pilar 7 — Curadoria opinionada]. Hipótese: iniciante que recebe tokens na carteira e depois decide reaplicar tem mais contexto do que iniciante que pressiona "reinvestir" sem saber o que isso significa.
Pilar 4 — Transparência financeira total antes do commit: card "Você vai receber" com breakdown por token + total em R$ + timestamp, antes de qualquer assinatura. [pancake-final § Pilar 4]. Hipótese: usuário que vê o total em R$ antes de confirmar tem menos chance de cancelar surpreso com o valor na carteira.

⚪ Novo

Opção "Reinvestir no pool" como alternativa nativa ao claim (compound). Não documentado como feature padrão nos relatórios de concorrentes — Uniswap e Pancake exigem claim manual + novo aporte para reinvestir. Justificativa: compound de taxas em LP é prática comum de intermediários; oferecer como opção nativa reduz gas (1 tx vs 2 tx) e reduz fricção para quem quer manter posição crescendo. Risco: usuário que seleciona "Reinvestir" sem entender pode ficar confuso por não ver tokens na carteira. Mitigação: aviso pedagógico inline ao selecionar a opção + copy de sucesso específico ("Taxas reinvestidas. Sua posição aumentou."). Evidência futura: taxa de seleção de "Reinvestir" vs "Receber"; se marginal, pode ser rebaixado para feature avançada.
Aviso de gas como % do valor das taxas (em vez de aviso absoluto de "gas alto"). Não documentado nos relatórios como forma de sinalização de gas. Justificativa: gas "R$ 3,20" pode ser aceitável para coleta de R$200, mas absurdo para coleta de R$4. A sinalização relativa é a única que traduz o dado para a decisão real do usuário. Risco: cálculo de "% do valor" exige que as duas estimativas (gas e taxas) sejam coerentes; se uma for stale, a porcentagem é enganosa. Mitigação: timestamps visíveis de ambos os cálculos. Evidência futura: taxa de abandono da tela quando aviso de gas > 50% é exibido.
"Reinvestir no pool" desabilitado quando posição está out-of-range — sem precedente documentado como fricção observada em Uniswap ou Pancake. Justificativa: reinvestir em posição out-of-range exigiria swap interno dos dois tokens para restaurar a proporção correta do range — operação com slippage implícito que o iniciante não visualiza. Desabilitar com label contextual ("Disponível somente quando a posição está ativa") previne que o iniciante descubra esse comportamento via erro silencioso. Evidência futura: taxa de toque em "Reinvestir" quando desabilitado — se alta, reavaliar se um bottom sheet explicativo é mais adequado que apenas label de desabilite.

Trade-offs e segunda ordem

"Reinvestir no pool" exige lógica de compound (zapear as duas taxas de volta para a posição existente, respeitando a proporção do range). Custo de implementação real; na versão MVP pode ser omitido e adicionado após validação da demanda.
Polling de gas a cada 30s enquanto o usuário está na tela tem custo de request. Polling para quando a tela perde o foco (tab em background, app minimizado) — custo de lifecycle management no frontend.
Taxas como snapshot vs taxas em tempo real: exibir o valor do momento de abertura (não atualizar em tempo real) evita que o número "dance" enquanto o usuário decide. O custo é que o valor final coletado pode diferir levemente. Aceitar com copy claro ("pode variar levemente até a confirmação").
i18n dos valores monetários exige Intl.NumberFormat com locale pt-BR — custo pontual de implementação, mas valor recorrente.

Tela 04 — Suas Posições: Seletor de Rede expandido

1. Função da tela

Permite ao usuário filtrar suas posições de liquidez por rede blockchain, exibindo o seletor em formato de bottom sheet (mobile) ou dropdown inline (desktop) a partir do botão "Rede" na toolbar de filtros. Foco em intermediário que tem posições cross-chain; iniciante deve conseguir entender a lista sem decodificar vocabulário técnico.

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

2.1 Botão de filtro "Rede" na toolbar (estado fechado — referência)

Label: Rede v (com chevron)
Quando todas as redes estão selecionadas (default): Todas as redes v
Quando rede específica selecionada: [Nome da rede] v + ícone da rede à esquerda
Badge numérico: ausente quando default (Todas as redes); Rede (N) quando N redes específicas selecionadas e difere do default — paridade de affordance com filtros Status e Protocolo

2.2 Seletor de rede (bottom sheet no mobile / dropdown no desktop) Estrutura hierárquica em três seções com header humanizado:

Seção A — "Todas as redes" (agregado)

Opção: Todas as redes + ícone composto (mosaico de logos)
Default selecionado; checkbox visual
Microcopy inline: "Agrega posições de todas as redes em uma lista"

Seção B — "Rápidas e baratas" (header de seção)

Base · Arbitrum · OP Mainnet · Polygon
Cada item: ícone colorido da rede (reconhecimento visual) + label + badge de gas estimado — ~R$ 0,05 gas (calculado pela mediana da última semana, atualizado diariamente)

Seção C — "Outras redes" (header de seção)

Ethereum · Unichain · Monad · Tempo · X Layer · … (expansível)
Mesmo padrão: ícone + label + badge de gas
Redes com badge Novo ou Beta mostram tooltip on-tap com 1 frase contextual (ver §5 Microcopy)

2.3 Sinalização de estado ativo

Rede selecionada: item com background destacado + check à direita
Nenhuma rede selecionada (estado inválido): impossível — selecionar uma rede desseleciona "Todas as redes" e vice-versa; múltiplas redes individuais podem ser combinadas

2.4 CTA de aplicação (mobile)

Botão fixo no rodapé do bottom sheet: Aplicar filtro
Desktop: aplicação imediata ao clicar na rede (sem botão extra — convenção de dropdown)

Cosméticos (polish posterior)

Animação de abertura do bottom sheet (slide-up 280ms)
Divider sutil entre seções A / B / C
Ícones de rede com tamanho padronizado (20 × 20 px)

3. Regras de negócio

Seleção

Todas as redes é mutuamente exclusivo com seleção individual; clicar em Todas as redes desmarca todas; clicar em qualquer rede individual desmarca Todas as redes automaticamente.
Múltiplas redes individuais podem ser combinadas (ex.: Base + Arbitrum) — lista de posições mostra apenas as redes selecionadas.
Selecionar rede única também restringe o flow + Nova posição para criar na rede selecionada (heranças de comportamento do hub de posições).

Exibição condicional

Redes com count(posições do usuário) == 0 aparecem na lista mas ficam ligeiramente esmaecidas (opacity 60%) com microcopy inline: "Você não tem posições nesta rede". Não são ocultadas — usuário pode filtrar pra confirmar isso.
Badge Novo: exibido por 60 dias após integração da rede; acompanhado obrigatoriamente de tooltip de contexto (ver §5).
Badge Beta: exibido enquanto a rede estiver em estágio de integração parcial; tooltip com aviso de instabilidade potencial.

Gas badge

Valor: mediana das últimas 168h (7d) de transações de addLiquidity naquela rede, convertido para BRL pelo câmbio atual.
Atualização: diária às 00:00 UTC.
Se dados indisponíveis: badge não renderiza (não exibe "—" nem "N/A").

Propagação de estado

Ao fechar o seletor (confirm no mobile / click-outside no desktop), o filtro de rede atualiza a lista de posições e propaga ao header de contagem (N posições).
Se a rede selecionada resultar em lista vazia, aciona o estado de empty state condicional da Tela 06 (verificar se posições existem nessa rede ou se filtro as ocultou).

4. Estados não-triviais

Vazio — nenhuma posição em nenhuma rede Não afeta o seletor de rede em si; o seletor ainda exibe todas as redes disponíveis. A lista de posições fica vazia independente da seleção de rede.

Loading — carregando redes suportadas

Skeleton de itens de lista no interior do seletor (3 placeholders por seção).
Botão Rede v na toolbar fica disabled enquanto lista carrega.
Timeout: se carregamento excede 5s, exibe lista em cache local (redes previamente vistas) + badge discreto Atualizando….

Erro — falha ao carregar lista de redes

Seletor abre com mensagem inline: "Não foi possível carregar a lista de redes. [Tentar novamente]"
Fallback: lista em cache da última sessão (se disponível), com aviso "Redes desatualizadas — clique para atualizar".

Rede sem suporte ao par/protocolo selecionado (filtro cruzado)

Quando o filtro Protocolo está ativo (ex.: "Posição com hooks"), redes que não suportam aquele protocolo ficam desabilitadas com tooltip: "Este tipo de posição não está disponível nesta rede".

Modo sem wallet / desconectado

Seletor de rede permanece funcional (discovery pública não requer identidade).
Gas badges ainda são exibidos (dados públicos de rede).
Itens esmaecidos por "sem posições" desaparecem — sem identidade, sem dados de posição.

Rede errada (wallet ativa em rede diferente da selecionada)

Banner inline no bottom sheet: "Sua carteira está conectada à [Rede X]. Para criar posições em [Rede Y], você precisará trocar de rede."
Não bloqueia a seleção de filtro (filtrar é leitura, não escrita).

5. Microcopy crítico

Botão de filtro (toolbar)

Default: Todas as redes ↓
1 rede: Base ↓ (com ícone da rede)
N redes: Rede (3) ↓
Loading: Rede ↓ (spinner pequeno)

Headers de seção

Seção A: — (sem header; Todas as redes é autodescritivo)
Seção B: Rápidas e baratas
Seção C: Outras redes

Gas badges

Formato: ~R$ 0,05 gas / ~R$ 15,00 gas
Tooltip no badge i: "Custo médio estimado de uma transação de liquidez nesta rede nos últimos 7 dias, em reais."

Tooltip para badge Novo (ex.: rede Tempo)

"Tempo — L2 de alta performance, integrada em 2026. Gas muito baixo (~R$ 0,01). Liquidez ainda em crescimento."

Tooltip para badge Beta

"Esta rede está em integração parcial. Algumas funções podem estar indisponíveis ou instáveis."

Item esmaecido (sem posições nesta rede)

Inline: "Sem posições nesta rede"

CTA de aplicação (mobile)

Aplicar filtro

Rede incompatível com protocolo (disabled)

Tooltip: "Este tipo de posição não está disponível em [Rede]."

6. Rastreabilidade obrigatória

🟢 Herdado

Default Todas as redes agrega cross-chain automaticamente — replicação consciente do padrão validado no Uniswap; iniciante nunca precisa configurar para ver tudo. [uniswap suas-posicoes-04 § Insight 1]
Ícones coloridos por rede + label textual — reconhecimento visual sem leitura obrigatória. [uniswap suas-posicoes-04 § Insight 2]
Badge Novo/Beta em redes recém-integradas — sinal de produto vivo, construção de confiança com intermediário. [uniswap suas-posicoes-04 § Insight 3]
Filtros com affordance de estado ativo (badge numérico quando diferente do default) — paridade de affordance entre os filtros da toolbar. [uniswap consolidado suas-posicoes § Cosmética — Filtros sem indicador de estado ativo]

🔴 Corrige

Categorização humanizada em vez de catálogo plano — Uniswap lista 9+ redes sem distinção semântica; iniciante pode escolher Ethereum (gas $15) sem saber que Base faz o mesmo por $0,05. A divisão Rápidas e baratas / Outras redes elimina escolha cega com consequência financeira. [uniswap suas-posicoes-04 § Fricção 1 — catálogo sem categorização]
Label textual Rede v no botão de filtro — Uniswap usa ícone composto sem texto; os outros filtros têm label (Status v, Protocolo v), criando assimetria de affordance. [uniswap suas-posicoes-04 § Fricção 2 — affordance fraca do filtro de rede]
Tooltip contextual obrigatório em badges Novo/Beta — badge Novo sem contexto é gatilho de curiosidade sem entrega de informação; tooltip de 1 frase resolve sem poluir a lista. [uniswap suas-posicoes-04 § Fricção 3 — Tempo sem contexto]

🟡 Captura

Seletor categorizado por adequação ao usuário (Rápidas e baratas / Outras redes) em vez de catálogo técnico (L1 / L2 / app-chain). A oportunidade da indústria é que todos os concorrentes (Uniswap, 1inch, Curve, PancakeSwap) listam redes em catálogo plano. Hipótese de diferenciação: usuário iniciante/intermediário escolhe rede por custo e praticidade, não por arquitetura técnica — categorizar por outcome (Rápidas e baratas) torna a decisão de rede uma decisão de UX, não de infra. [uniswap suas-posicoes-04 § Oportunidade — seletor por finalidade]
Gas badge em BRL por rede — combina com geo-default BR/LatAm (Pilar 5). Nenhum concorrente exibe custo estimado de gas contextualizado por rede e moeda local diretamente no seletor de rede. Hipótese: reduz evasão de usuários BR que escolhem Ethereum por familiaridade de nome e são surpreendidos pelo custo. [pancake-relatorio-final § Fricção 2 — i18n parcial] [uniswap-relatorio-final § Pilar 4 — Default contextual em camadas]

⚪ Novo

Redes do usuário com count(posições) == 0 esmaecidas mas não ocultas — sem origem direta nos relatórios. Justificativa: esconder a rede seria A2 (sobre-escopar) e criaria confusão se o usuário espera ver uma rede que sabe que existe; esmaecida comunica "você não tem posições aqui" sem impedir exploração. Risco: pode parecer desabilitada. Evidência a coletar: teste A/B entre "escondida", "esmaecida" e "normal" medindo confusão vs. completeness.
Gas badge com atualização diária (não real-time) — tempo real exigiria polling constante; diário é suficiente para decisão de rede (gas não muda de tier no mesmo dia para a maioria das redes L2). Custo técnico inferior sem comprometer utilidade.

7. Trade-offs e segunda ordem

Categorização editorial das redes (Rápidas e baratas / Outras) exige critério explícito e manutenção contínua: quando uma nova chain é integrada, alguém decide em qual seção ela entra. Se Ethereum melhorar drasticamente o gas (improvável no horizonte de 2 anos), a categorização precisa de revisão. Aceitar como custo de produto opinionado.

Gas badge em BRL exige pipeline de dados de preço de gas por rede + câmbio BRL/USD. Aumenta dependência de APIs externas; falha nessa pipeline degrada o badge para ausente (não para dado errado). Implementar com fallback gracioso obrigatório.

Bottom sheet no mobile (Pilar 5) é mais complexo de animar que dropdown simples. Custo de componente; ganho: tapping area maior, mais espaço para seções humanizadas. Justificado para seletor com categorias e tooltips.

i18n: gas badge em BRL é locale PT-BR — para usuários em outro locale, o badge precisaria converter para a moeda local. Escopo inicial: exibir em BRL para locale PT-BR; para outros locales, exibir em USD com mesmo padrão. Adiciona 1 variante de string por badge.

Suas Posições — Tela 03: Hub vazio — empty state prescritivo

1. Função da tela

Transforma o estado de "carteira conectada sem posições" de placeholder passivo em assistente ativo de onboarding — lê os saldos on-chain da wallet e sugere uma primeira posição concreta baseada no que o usuário já tem. Perfil-foco: iniciante conectando a carteira pela primeira vez ou intermediário retornando após fechar todas as posições.

2. Componentes / elementos

Estrutural — define o paradigma da tela:

2.1 Header de boas-vindas ativa (substitui bloco de rendimentos condicionalmente — só quando count(posições) == 0)

H1: "Suas posições de liquidez"
Subtítulo ativo: "Você ainda não tem posições. Veja por onde começar ↓"
Ausente: bloco "0 Rendimentos acumulados — Recolher rendimentos [disabled]" — não renderizar quando count(posições) == 0 (esta é a correção estrutural central desta tela).

2.2 Card de sugestão prescritiva (o coração desta tela; conteúdo varia por variante)

Variante A — saldo compatível para LP (2 tokens com saldo > $10 equivalente):

Texto personalizado: "Você tem [R$ X em Token A] e [R$ Y em Token B]. Pool sugerida para começar: [Par], taxa [Z%]. Retorno médio nos últimos 30 dias: ~P% ao ano (estimativa 30d, sem Impermanent Loss). Esta é uma configuração conservadora para primeira posição."
Badge de transparência clicável: "Sugestão baseada em: par com maior liquidez nos seus tokens [ver critérios]"
CTA primário: "Criar essa posição" — pré-configura par + modo (Simples ou Concentrado conforme o par) + range conservador + fee tier dominante para o par
Link secundário: "Entender os riscos antes de continuar →" — abre explainer de Impermanent Loss + pool risk (sem ser modal bloqueante; abre em painel lateral ou nova aba)
Terceiro link discreto: "Configurar manualmente →" — para quem quer escolher par diferente

Variante B — saldo em apenas 1 token (count(tokens > $10) == 1):

Texto: "Você tem [R$ X em Token A]. Para adicionar liquidez em [par popular com Token A], você precisará de uma parte em [Token B]. Quer comprar [Token B] primeiro?"
CTA primário: "Comprar [Token B]" → leva ao fluxo de Swap com Token B pré-selecionado como destino
Link secundário: "Ver pools com só [Token A] →" (single-sided pools se disponível)
Link terciário: "Configurar manualmente →"

Variante C — saldo insuficiente (total < $10 equivalente, mas saldo > $0):

Texto: "Para ganhar rendimento com liquidez, você precisa de criptos em carteira. Compre via PIX — taxas a partir de 1,5%."
CTA primário: "Comprar com PIX" → leva ao fluxo de compra BR
Link secundário: "Já tenho cripto em outra exchange — Trazer para cá →" → leva ao fluxo de depósito
Sem sugestão de par (prematuro sem saldo)

Variante D — saldo nulo ou erro de leitura de saldo:

Texto genérico: "Para ganhar rendimento com suas criptos, você precisa de saldo em carteira. Compre via PIX ou traga de outra exchange."
CTA A: "Comprar com PIX"
CTA B: "Trazer de outra exchange"
Badge discreto quando Variante D acionada por erro (não por saldo nulo): "Não foi possível ler seu saldo — exibindo orientação genérica."

2.3 Toolbar de filtros (preservada para consistência arquitetural, em estado inativo)

Exibida com opacidade reduzida (não clicável)
Texto inline substituindo os filtros: "Sem posições para filtrar"
Alternativa a avaliar em visual design: substituir por spacer com mesma altura (evitar confusão de "por que não funciona")

2.4 Cards educacionais bifurcados (abaixo do card prescritivo)

Card A — iniciante: título "Primeira vez? Como funciona ganhar com liquidez", subtítulo "Leitura de 3 min — sem jargão técnico", tag "Para começar"
Card B — intermediário: título "Comparando estratégias de provisão de liquidez", tag "Para quem já usa DeFi"
Cada card dismissível individualmente (botão X discreto no canto); estado de dismiss persistido por usuário (localStorage ou preferência linked à wallet)
Hierarquia visual explícita: Card A em destaque (maior), Card B em secondary (menor)
Após dismiss de ambos: área vira spacer neutro; botão "Reativar guias →" disponível nas configurações

2.5 Sidebar de discovery (idêntica à T01 e T02 — continuidade arquitetural)

"Pools em destaque" com as mesmas pools da T01/T02

2.6 CTA secundário de entrada manual (abaixo dos cards educacionais, hierarquicamente abaixo do prescritivo)

Label: "Adicionar posição manualmente →"
Peso visual baixo (link-style, não botão primário)

Cosmético:

Ícone de "sugestão" no card prescritivo (bússola ou estrela — a definir em visual design)
Animação de transição do skeleton (loading de saldo) para o conteúdo personalizado
Micro-animação de entrada do card prescritivo (fade-in após leitura de saldo)

3. Regras de negócio

Condicionalidade desta tela: renderizada quando count(posições da wallet na Kotai) == 0. Ao criar a primeira posição (via qualquer caminho), redirect para T02.
Leitura de saldos on-chain: executada ao montar a tela. Timeout de 5s — se não completar em 5s, exibir Variante D com badge de erro. Não persistir saldos; ler sempre em tempo real. Não requer aprovação adicional de permissão (read-only).
Lógica de seleção de variante:
- count(tokens com saldo > $10 equivalente) ≥ 2 → Variante A (sugere par)
- count(tokens com saldo > $10 equivalente) == 1 → Variante B (sugere split)
- count(tokens com qualquer saldo > $0) > 0 mas todos < $10 → Variante C (on-ramp)
- saldo total == $0 OU erro de leitura → Variante D
Pool sugerida (Variante A) — critérios de seleção (visíveis via "ver critérios"):
- Par formado pelos dois tokens de maior saldo em BRL
- Fee tier com maior volume 7d para aquele par
- Range: ±20% para Modo Concentrado / full range para Modo Simples
- Pool com TVL ≥ $100k e pelo menos 30 dias de histórico (evita pool nova ou de cauda)
- Modo recomendado: Simples (full range) para iniciante (menor gestão ativa exigida)
CTA "Criar essa posição": ao clicar, vai para criar-pool-01 com par + modo + range + fee pré-configurados. O usuário pode editar qualquer parâmetro dentro do fluxo criar-pool; esta tela apenas define os defaults de entrada.
Cards educacionais: após dismiss individual, estado persistido. Não reaparecem na mesma sessão nem nas próximas (opt-out permanente por card). Botão de reativar nas configurações.
Toolbar inativa: exibida para preservar consistência arquitetural com T02 (usuário reconhece o layout ao criar posições). Texto "Sem posições para filtrar" elimina confusão de "por que não funciona".
Redirect após criação: ao detectar que count(posições) passou de 0 para 1+ (event listener ou polling a cada 15s enquanto a tela está visível), redirect automático para T02 com toast "Posição criada com sucesso."

4. Estados não-triviais

Estado	Comportamento
Loading de saldo	Skeleton no card prescritivo preservando dimensões; restante da tela (header, toolbar inativa, cards edu, sidebar) carregados independentemente
Variante A (2 tokens)	Card prescritivo com par + APR estimado + CTA direto "Criar essa posição"
Variante B (1 token)	Card prescritivo com sugestão de split + CTA "Comprar [Token B]"
Variante C (saldo insuficiente)	Card prescritivo com on-ramp BR como CTA primário
Variante D (saldo nulo / erro)	Card genérico com dois CTAs (PIX + transferência); badge de erro discreto se motivado por timeout
Erro de leitura (timeout >5s)	Variante D com badge "Não foi possível ler seu saldo — exibindo orientação genérica."
Após dismiss de Card A	Card A some com animação; Card B permanece visível
Após dismiss de ambos	Área vira spacer neutro; sem colapso visual abrupto do layout
Após criação de posição	Redirect para T02 com toast "Posição criada com sucesso."
Carteira desconectada	Redirect para T01
Rede errada	Banner informativo (mesmo padrão de T02): "Suas posições em [Rede] ficam indisponíveis nesta rede. [Trocar para Rede]"
Mobile	Card prescritivo ocupa 100% da largura; sidebar colapsa para abaixo dos cards educacionais; CTA "Criar essa posição" como botão full-width dentro do card; CTA manual como link abaixo dos cards edu

5. Microcopy crítico

Elemento	Texto PT-BR
Header subtítulo	"Você ainda não tem posições. Veja por onde começar ↓"
Variante A
Card texto	"Você tem [R$ 5.250 em USDC] e [R$ 3.100 em ETH]. Pool sugerida para começar: USDC/ETH, taxa 0,05%. Retorno médio nos últimos 30 dias: ~4,9% ao ano."
Caveat IL	"(estimativa 30d, sem Impermanent Loss) ⓘ"
Tooltip caveat	"Estimativa baseada nas tarifas coletadas pelos provedores desta pool nos últimos 30 dias. Impermanent Loss pode reduzir seu retorno real dependendo da variação de preço entre os tokens."
Nota conservadora	"Esta é uma configuração conservadora para primeira posição."
Badge transparência	"Sugestão baseada em: par com maior liquidez nos seus tokens [ver critérios]"
CTA prescritivo	"Criar essa posição"
Link explainer	"Entender os riscos antes de continuar →"
Link manual	"Configurar manualmente →"
Variante B
Card texto	"Você tem R$ 8.200 em ETH. Para adicionar liquidez em ETH/USDC, você precisará de uma parte em USDC. Quer comprar USDC primeiro?"
CTA split	"Comprar USDC"
Link alternativo	"Ver pools com só ETH →"
Link manual	"Configurar manualmente →"
Variante C
Card texto	"Para ganhar rendimento com liquidez, você precisa de criptos em carteira. Compre via PIX — taxas a partir de 1,5%."
CTA on-ramp	"Comprar com PIX"
Link transferência	"Já tenho cripto em outra exchange — Trazer para cá →"
Variante D
Card texto genérico	"Para ganhar rendimento com suas criptos, você precisa de saldo em carteira. Compre via PIX ou traga de outra exchange."
CTA A	"Comprar com PIX"
CTA B	"Trazer de outra exchange"
Badge erro leitura	"Não foi possível ler seu saldo — exibindo orientação genérica."
Comum
Toolbar inativa	"Sem posições para filtrar"
Card edu A título	"Primeira vez? Como funciona ganhar com liquidez"
Card edu A subtítulo	"Leitura de 3 min — sem jargão técnico"
Card edu A tag	"Para começar"
Card edu B título	"Comparando estratégias de provisão de liquidez"
Card edu B tag	"Para quem já usa DeFi"
CTA manual	"Adicionar posição manualmente →"
Loading saldo	"Analisando sua carteira..."
Toast pós-criação	"Posição criada com sucesso."

6. Rastreabilidade obrigatória

🟢 Herdado

Layout de três zonas preservado mesmo em empty state — o Uniswap T06 preserva a arquitetura de header / toolbar / lista / sidebar mesmo com lista vazia; iniciante aprende a estrutura da tela sem precisar de posição para isso. A Kotai herda o paradigma. [uniswap suas-posicoes § Empty state como espaço editorial — tela 6]
Sidebar de discovery pública independente do estado de posições — discovery não exige identidade; funciona igual com ou sem posições. [uniswap suas-posicoes § Separação visual entre gestão pessoal e discovery pública — telas 5 e 6]
Progressive disclosure: CTA manual existe e é acessível — avançado que quer ignorar a sugestão tem caminho direto sem fricção adicional. [uniswap-final § Progressive disclosure como padrão arquitetural]
Empty state como instrução acionável — empty state do Uniswap em outros fluxos entrega instrução na língua do ato. A Kotai herda o princípio e o eleva: instrução personalizada com base nos saldos. [uniswap-final § Estados (vazio, erro, transitório) como instrução acionável]
Pedagogia embutida no ponto de decisão — cards educacionais contextuais no ponto de maior indecisão do usuário. [pancake-final § Pedagogia embutida no ponto de decisão]

🔴 Corrige

Header "0 Rendimentos acumulados — Recolher rendimentos [disabled]" sem condicional de estado — ocupa ~30% do espaço útil de onboarding comunicando para o iniciante que ele "não tem nada" — primeira impressão da seção como status report vazio. Corrigido tornando o header condicional: se count(posições) == 0 → header de boas-vindas ativa; se count(posições) > 0 → header de rendimentos (T02). [uniswap suas-posicoes § Fricção estrutural: header rewards zerado sem condicional de estado — telas 1 e 6]
CTAs paralelos sem hierarquia pedagógica — Uniswap T01/T05: "Explorar pools" (outline) e "Nova posição" (primário rosa) com tamanhos similares, onde iniciante deveria explorar antes de criar. O produto destaca "Nova posição" por convenção de UI mas a realidade pedagógica é o inverso. Corrigido com hierarquia visual explícita: card prescritivo > cards educacionais > CTA manual. [uniswap suas-posicoes § Fricção cosmética: CTAs paralelos sem hierarquia pedagógica — telas 1 e 5]
Empty state genérico ignorando saldo disponível da wallet — "Crie uma nova posição para começar a ganhar tarifas" não considera o que o usuário tem na carteira; força jornada de descoberta completa (explorar pools → escolher par → configurar range). Específico converte; genérico não. [uniswap suas-posicoes § Oportunidade: empty state prescritivo baseado em saldo da wallet — telas 1 e 6]
Cards educacionais fixos voltados a power user nas telas de maior presença de iniciante — "Fornecer liquidez em protocolos diferentes" e "Hooks no v4" nos estados T05 e T06 (100% de audiência iniciante). Corrigido com cards bifurcados por nível: Card A em linguagem de outcome sem jargão; Card B para intermediário. [uniswap suas-posicoes § Fricção estrutural: conteúdo editorial voltado a power user — telas 5 e 6]

🟡 Captura

Empty state prescritivo baseado em saldo on-chain [uniswap suas-posicoes § Oportunidade: empty state prescritivo baseado em saldo da wallet — telas 1 e 6] — passa nas 4 perguntas-teste: (1) ✓ todos os concorrentes têm empty state genérico; (2) ✓ afeta iniciante diretamente; (3) ✓ leitura on-chain + regras editoriais = factível; (4) ✓ empty state passa de placeholder para assistente. Hipótese concreta: iniciante com USDC + ETH vê "Pool sugerida: USDC/ETH 0,05%" e tem um caminho concreto em vez de ter que descobrir o par ideal sozinho. Evidência a coletar: taxa de criação de primeira posição via CTA prescritivo vs CTA manual; comparar por variante (A/B/C/D).
On-ramp BR first quando saldo insuficiente (Variante C) — [pancake-final § Pilar 7 — Localização BR/LatAm como infraestrutura] + [uniswap-final § Pilar 1 — Localização BR/LatAm como infraestrutura] — usuário BR sem saldo mas com intenção vê PIX como primeiro caminho em vez de Moonpay global. Hipótese: taxa de abandono no funil de funding cai quando on-ramp local é o default visível.
Cards educacionais bifurcados por nível de familiaridade [uniswap suas-posicoes § Fricção estrutural: conteúdo editorial voltado a power user — alternativa concreta] — dois cards servem os dois perfis sem excluir nenhum; hierarquia visual coloca iniciante em primeiro.

⚪ Novo

Variante B — sugestão de split antes de LP — sem equivalente nos DEXs analisados. Nenhum DEX detecta saldo único e sugere split integrado no empty state de LP. Justificativa: LP em par de dois tokens requer os dois tokens; usuário com apenas ETH que quer entrar em USDC/ETH precisa comprar USDC primeiro. Se o produto não guia essa etapa, abandona ou tenta criar posição com apenas um token (erro de UX). O ganho é alto (resolve bloqueio real de entrada); o risco é moderado — precisamos garantir que a sugestão de split não incentive venda desnecessária quando o usuário poderia usar um pool single-sided. Evidência a coletar: % de usuários em Variante B que completam a compra e depois criam posição vs taxa de abandono vs rate de clique em "Ver pools com só [Token A] →".
Timeout de 5s com fallback para Variante D — decisão técnica de UX sem origem explícita nos relatórios. Justificativa: leitura de saldo on-chain pode falhar (RPC overload, latência, rede errada). Loading infinito é pior que Variante D genérica. O badge "Não foi possível ler seu saldo" preserva honestidade sem punir o usuário por uma falha de infra. Evidência a coletar: % de timeouts de leitura de saldo por rede — se >5%, investigar RPC alternativo.

7. Trade-offs e segunda ordem

Opinião editorial sobre "pool sugerida" — a lógica de Variante A (par pelos maiores saldos, fee tier com maior volume, range ±20%) é uma decisão de produto com risco de ser percebida como "você está enviando liquidez para a pool que a Kotai escolheu" ou "vocês recebem comissão por isso". Mitigação obrigatória: badge "Sugestão baseada em: [ver critérios]" clicável; critério explícito na página de configurações. Risco de curadoria: par sugerido pode mudar entre a sugestão e o clique em "Criar" se saldos mudarem.
Quatro variantes de card é complexidade de produto: cada variante é surface de microcopy, componente de UI e lógica de seleção separados. Para i18n, multiplica por 4 (PT-BR + EN + ES). Recomendação de MVP: lançar com Variantes A e D; adicionar B e C no segundo release após validar taxa de adoção da sugestão.
Leitura de saldo on-chain: requer permissão de read da wallet + RPC confiável + lógica de conversão em BRL. Se usuário nega permissão de read → Variante D. Se RPC falha → Variante D. Se preço do token indisponível (token exótico) → excluir da comparação ou exibir "Saldo em [Token]" sem equivalente BRL. Não armazenar saldos além da sessão.
Toolbar inativa: a escolha de preservar a toolbar desabilitada vs ocultá-la completamente precisa de validação em teste. Risco: usuários interpretam "Sem posições para filtrar" como erro (produto quebrado). Mitigação A: ocultar toolbar + substituir por spacer neutro com mesma altura (mais limpo, menos ruído). Mitigação B: manter toolbar mas com visual claramente desabilitado (opacidade 40%). Avaliar em teste de usabilidade antes de fixar.
Redirect para T02 após criação de posição: a detecção de "posição criada" exige event listener ou polling. Se o usuário abre o fluxo criar-pool em nova aba e retorna para T03, a tela precisa detectar e redirecionar. Polling a cada 15s enquanto a tela está em foreground é solução simples; event listener via wallet é mais elegante mas requer integração específica.
Variante B e single-sided pools: o link "Ver pools com só [Token A] →" só faz sentido se a Kotai suportar pools single-sided (CLAMM single-side, concentrated liquidity com range unilateral). Se não suportar no lançamento, omitir o link na Variante B para não criar expectativa de feature inexistente.
Conflito Pilar 5 (Mobile-first) vs card prescritivo em mobile: em mobile, o card prescritivo com texto + badge + CTA + dois links pode ficar denso. Decisão: em mobile, texto truncado com "Ver mais" inline; CTA full-width dentro do card; links comprimidos abaixo do CTA.

Pools — Tela 9 — Remover liquidez

Função da tela

Fluxo de saída de uma posição LP: o usuário (foco em iniciante que se assusta com o IL e intermediário que quer rebalancear) decide quanto da posição retirar (parcial ou total), vê o impacto real em tokens e R$, entende o IL realizado pela primeira vez como dado contextualizado — e confirma a transação. A ação é significativa: remove capital comprometido e finaliza ou reduz uma posição.

Ponto de entrada: CTA "Remover liquidez" de pools-07. Segundo ponto de entrada: aviso out-of-range em pools-07 ("Remover liquidez" inline).

Componentes / elementos

Estrutural (define o paradigma da tela)

Header de identidade da posição (sticky, herdado de pools-07 e pools-08)
- Par + protocolo + fee + ID: "ETH / USDC · V3 · 0,05% · #123456"
- Breadcrumb: "Ganhar rendimento › Minhas posições › ETH/USDC › Remover liquidez"
- Badge de status de range (herdado — a posição pode estar out-of-range, o que muda a composição de saída).
Seletor de percentual de remoção (componente central — o quanto remover)
- Chips de atalho: 25% | 50% | 75% | 100% — tap-targets de largura mínima 44px em mobile.
- Input de percentual customizável: slider deslizante + campo numérico editable (para quem quer precisão, ex: 37%).
- Default: "100%" pré-selecionado — usuário que chega aqui provavelmente quer sair completamente. Se vier do aviso out-of-range, default é 100%; se vier do menu de gestão com posição ativa, default é 100% mas o usuário pode ajustar.
- Chips e slider atualizam o card de preview em tempo real.
Card de preview de saída (o que o usuário vai receber ao percentual selecionado)
- Título: "Você vai receber"
- Linha de token A: 0,87 ETH ≈ R$ 16.133 (calculado pelo percentual)
- Linha de token B: R$ 16.194,75 USDC
- Total em R$: Total ≈ R$ 32.328
- Atualiza em tempo real conforme o slider muda.
- Abaixo do total: "+ 0,003 ETH e 4,20 USDC em taxas acumuladas incluídas." — taxas pendentes são sempre incluídas na remoção.
Card de resultado da posição (IL contextualizado — componente pedagógico)
- Título: "Resumo da sua posição"
- Linha 1: Valor aportado: ≈ R$ 43.390
- Linha 2: Valor a retirar (ao percentual atual): ≈ R$ 32.328
- Linha 3: "Variação de composição (IL): -R$ 240 (-0,55%)" — valor absoluto negativo em âmbar, não vermelho (não é uma perda definitiva de produto — é consequência matemática de LP).
- Linha 4: Taxas acumuladas: +R$ 59,80
- Linha de resultado líquido: Resultado líquido: ≈ -R$ 180,20 (-0,41%) — abaixo das linhas. Pode ser positivo se taxas superaram o IL.
- Caption pedagógica abaixo do card:
  - Se resultado negativo: "A variação de composição (IL) foi maior que as taxas acumuladas nesta posição. Se você tivesse mantido os tokens sem aportar, estaria com R$ 180 a mais — mas as taxas coletadas reduziram essa diferença."
  - Se resultado positivo: "As taxas acumuladas superaram a variação de composição. O resultado líquido desta posição foi positivo."
- Este card é o momento em que o IL se torna real para o usuário — contextualizá-lo como consequência matemática (não falha do produto) é crítico.
Estimativa de gas
- Linha simples: "Gas estimado: ≈ R$ 5,40" (nunca em GWEI).
- Timestamp: "Estimativa às 14:32 · atualiza a cada 30s."
CTA de progressão (sticky rodapé em mobile, inline em desktop)
- "Confirmar remoção" — primário, ativo após carregamento dos dados.
- Remoção de 100%: label do CTA muda para "Encerrar posição" — semântica precisa do ato.
- Quando aguardando assinatura: "Aguardando sua assinatura na carteira…"
- Quando tx enviada: navega para estado de sucesso/falha (inline nesta tela).

Cosmético (polish, vai depois do estrutural)

Link "O que é IL e como ele afeta minha saída?" — link pedagógico discreto abaixo do card de resultado, abre bottom sheet com explicação completa em 4 linhas + link para simulador.
Configurações avançadas ▾ — colapsado: tolerância de variação de preço (slippage) + "Transação expira após". Padrão herdado de pools-04 e pools-05.
Link "← Voltar para minha posição" — retorna para pools-07 sem iniciar transação.

Regras de negócio

Herança de contexto obrigatória: recebe positionId da URL. Sem contexto, redireciona para pools-01.
Taxas acumuladas incluídas automaticamente: toda remoção — parcial ou total — inclui as taxas pendentes. Não há opção de "remover liquidez sem coletar taxas" (simplificação pró-iniciante; avançado pode usar interface de contrato direto se necessário).
Composição de saída depende do range status:
- In-range: saída proporcional ao split atual (ex: ~50% ETH, ~50% USDC).
- Out-of-range (preço acima da faixa): saída ~100% ETH (todo o capital está em ETH porque o pool comprou ETH com USDC enquanto o preço subia fora do range).
- Out-of-range (preço abaixo da faixa): saída ~100% USDC.
- A composição real é calculada on-chain; o preview exibe a estimativa com nota: "Composição exata calculada no momento da transação."
Default de percentual:
- Entrada via aviso out-of-range de pools-07: 100% pré-selecionado.
- Entrada via CTA "Remover liquidez" de pools-07 (posição ativa): 100% pré-selecionado (a maioria dos usuários que clica em "Remover liquidez" quer sair completamente; quem quer remoção parcial ajusta).
Remoção < 100%: a posição continua ativa com o percentual restante. Nenhuma confirmação adicional necessária — não é ação de Tier 1 em sua totalidade.
Remoção = 100%: label do CTA muda para "Encerrar posição" — microcopy preciso do ato. Após confirmação, a posição é removida e o NFT de LP é queimado on-chain. Aviso informativo (não bloqueante): "Esta ação encerra sua posição permanentemente. Capital e taxas vão para a sua carteira."
Gas stale (> 60s): badge âmbar + "Gas pode ter mudado. Estimativa atualizada."
Preço moveu > 2% durante a revisão: banner não bloqueante + "O preço mudou desde que você abriu esta tela. Preview atualizado." Recalcula o card de preview automaticamente.
Aprovações ERC-20: remoção de liquidez geralmente não exige nova aprovação (é queima de LP token já aprovado no mint). Se necessário, exibir etapa com sub-copy explicativo (padrão de pools-05).

Estados não-triviais

Estado	Comportamento
Loading	Skeleton em seletor de %, card de preview e card de resultado. Label: "Carregando dados da posição #123456…"
Posição out-of-range (preço acima da faixa)	Badge ⬜ no header. Card de preview mostra ~100% ETH. Nota: "Posição fora da faixa — saída é ~100% em ETH."
Posição out-of-range (preço abaixo da faixa)	Badge ⬜ no header. Card de preview mostra ~100% USDC. Nota: "Posição fora da faixa — saída é ~100% em USDC."
Resultado líquido positivo	Caption: "As taxas acumuladas superaram a variação de composição. O resultado líquido desta posição foi positivo." Linha de resultado em verde.
Resultado líquido negativo	Caption pedagógica (ver componente 4). Linha de resultado em âmbar — não em vermelho (âmbar = atenção, não alarme).
Sem taxas acumuladas	Linha "Taxas acumuladas incluídas" mostra `R$ 0,00`. Sem comportamento especial.
Remoção 100% selecionada	CTA muda para "Encerrar posição". Aviso informativo inline (não bloqueante): "Esta ação encerra sua posição permanentemente. Capital e taxas vão para a sua carteira."
Preço moveu > 2%	Banner não bloqueante: "O preço mudou. Preview atualizado." Card de preview recalcula.
Aguardando assinatura	Spinner no CTA + "Aguardando sua assinatura na carteira…"
Tx enviada — aguardando confirmação	Estado inline: ícone loading + "Transação enviada. Aguardando confirmação…" + hash compacto + link "Ver no Etherscan ↗" + banner: "Você pode fechar esta tela. Os tokens aparecerão na sua carteira quando confirmado." Botão "← Voltar para minha posição" substituído por link "Ver status da transação" para evitar back-nav com transação em voo.
Sucesso — remoção parcial	Toast: "R$ 16.194 retirados da posição. Posição continua ativa com R$ X." → retorna para pools-07 com dados atualizados.
Sucesso — encerramento total	Banner in-place: "Posição encerrada. R$ 32.328 adicionados à sua carteira." CTA: "Ver catálogo de pools" (primário) + "Voltar para Minhas posições" (link).
Falha — slippage excedido	"Variação de preço maior que a tolerância. Tente de novo com tolerância maior em Configurações avançadas." CTA "Tentar de novo".
Falha — gas insuficiente	"Gas insuficiente. Aumente a tolerância em Configurações avançadas." CTA "Ajustar gas".
Falha — revert genérico	"Transação revertida. Nenhum fundo foi movido." CTA "Tentar de novo" + link "Ver detalhes do erro".
Rede errada	Banner: "Você está na rede [X]. Esta posição existe em [Y]. Mude para continuar." CTAs desabilitados com label contextual.
Wallet desconectada	Banner bloqueante: "Carteira desconectada. Reconecte para continuar." CTA "Conectar carteira".

Microcopy crítico (PT-BR)

Elemento	Texto
Breadcrumb	Ganhar rendimento › Minhas posições › ETH/USDC › Remover liquidez
Chips de atalho	25% \| 50% \| 75% \| 100%
Título do card de preview	Você vai receber
Linha de taxas incluídas	+ 0,003 ETH e 4,20 USDC em taxas acumuladas incluídas.
Título do card de resultado	Resumo da sua posição
Linha valor aportado	Valor aportado: ≈ R$ 43.390
Linha valor a retirar	Valor a retirar: ≈ R$ 32.328
Linha IL	Variação de composição (IL): -R$ 240 (-0,55%)
Linha taxas	Taxas acumuladas: +R$ 59,80
Linha resultado	Resultado líquido: ≈ -R$ 180,20 (-0,41%)
Caption — resultado negativo	A variação de composição (IL) foi maior que as taxas acumuladas nesta posição. Se você tivesse mantido os tokens sem aportar, estaria com R$ 180 a mais — mas as taxas coletadas reduziram essa diferença.
Caption — resultado positivo	As taxas acumuladas superaram a variação de composição. O resultado líquido desta posição foi positivo.
Nota de composição	Composição exata calculada no momento da transação.
Nota out-of-range (acima)	Posição fora da faixa — saída é ~100% em ETH.
Nota out-of-range (abaixo)	Posição fora da faixa — saída é ~100% em USDC.
Gas estimado	Gas estimado: ≈ R$ 5,40
Timestamp gas	Estimativa às 14:32 · atualiza a cada 30s.
Aviso encerramento	Esta ação encerra sua posição permanentemente. Capital e taxas vão para a sua carteira.
CTA remoção parcial	Confirmar remoção
CTA encerramento	Encerrar posição
Aguardando assinatura	Aguardando sua assinatura na carteira…
Tx enviada	Transação enviada. Aguardando confirmação…
Banner pode fechar	Você pode fechar esta tela. Os tokens aparecerão na sua carteira quando confirmado.
Sucesso parcial	R$ 16.194 retirados da posição. Posição continua ativa com R$ X.
Sucesso total	Posição encerrada. R$ 32.328 adicionados à sua carteira.
CTA pós-sucesso total (primário)	Ver catálogo de pools
Link pós-sucesso total	Voltar para Minhas posições
Slippage excedido	Variação de preço maior que a tolerância. Tente de novo com tolerância maior em Configurações avançadas.
Gas insuficiente	Gas insuficiente. Aumente a tolerância em Configurações avançadas.
Revert genérico	Transação revertida. Nenhum fundo foi movido.
Preço moveu	O preço mudou. Preview atualizado.
Rede errada	Você está na rede [X]. Esta posição existe em [Y]. Mude para continuar.
Link pedagógico IL	O que é IL e como ele afeta minha saída?

Rastreabilidade obrigatória

🟢 Herdado

Sticky de identidade da posição com par + protocolo + badge de range durante toda a tela de ação. Fonte: [uniswap posicao-populada-01 § Insight 1 — template de identidade persistente]
Gas em R$, nunca em GWEI. Fonte: [pancake-final § Pilar 5 — Localização BR/LatAm como infraestrutura]
Chips de percentual 25% / 50% / 75% / 100% — atalhos de quantidade eliminam cálculo cognitivo. Fonte: [uniswap/_consolidado/visualizar-pool.md § Insight — Presets chips em qualquer decisão financeira]
CTA desabilitado com label contextual. Fonte: [pancake-final § Pilar 2 — CTA dinâmico]
Diagnóstico específico por tipo de falha (slippage, gas, revert): nunca mensagem genérica. Fonte: [pancake-final § Insight — Transparência proativa antes do CTA]
Banner "pode fechar" durante tx pendente — elimina ansiedade de "preciso ficar aqui?". Fonte: [pancake-final § Pilar 2] + herdado de pools-06.
Configurações avançadas colapsadas por default: slippage e deadline para o avançado sem poluir o flow principal. Fonte: [uniswap-final § Progressive disclosure como padrão arquitetural]
Timestamp unificado de dados: preços e estimativas derivam do mesmo snapshot. Fonte: [uniswap/_consolidado/visualizar-pool.md § Fricção — Métricas vivas sem âncora de snapshot]

🔴 Corrige

IL não contextualizado no momento da saída → Card de resultado com breakdown explícito (aportado, a retirar, IL, taxas, resultado líquido) + caption pedagógica por situação. Concorrentes exibem apenas os tokens a receber; o impacto relativo ao aporte fica invisível. [uniswap/_consolidado/nova-posicao.md § Fricção — Ausência de estado do pool destino na janela de decisão] + [uniswap-final § Fricção 6 — Métricas DeFi sem decomposição, janela ou comparativo]
"Encerrar posição" como label do CTA quando remoção = 100%: CTA genérico "Confirmar" não comunica que a posição deixa de existir. [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência]
Composição de saída out-of-range invisível → Nota contextual quando a posição está fora da faixa explica que a saída será ~100% em um token. [uniswap/_consolidado/nova-posicao.md § Fricção — Ausência de estado do pool destino]
i18n parcial → Todo copy em PT-BR; R$ com locale; "IL" como secondary label (primary = "Variação de composição"). [pancake-final § Fricção 2]
Affordances nivelados para ações de risco diferente → CTA de encerramento ("Encerrar posição") com label preciso do ato; aviso inline informativo (não bloqueante). [uniswap-final § Fricção 7 — Affordances nivelados para ações de risco diferente]

🟡 Captura

Pilar 4 — Transparência financeira total: IL contextualizado como parte do resultado da posição, não como surpresa negativa. Card de resultado com resultado líquido (taxas vs IL) + caption pedagógica. [pancake-final § Pilar 4 — Educação contextual + Transparência financeira]. Hipótese: usuário que vê "as taxas reduziram a diferença" antes de confirmar a saída não interpreta a operação como falha do produto — calibra expectativa de LP.
Pilar 4 — Caption pedagógica condicional por situação (negativa vs positiva): dois templates simples baseados no resultado líquido. [pancake-final § Pilar 4] + [uniswap/_consolidado/pools.md § Oportunidade — Sistema pedagógico de métricas DeFi]. Hipótese: usuário com resultado negativo que lê "se você tivesse mantido os tokens, estaria com R$ 180 a mais — mas as taxas reduziram essa diferença" entende o trade-off de LP em vez de abrir ticket de suporte.
Pilar 3 — "Encerrar posição" como label preciso + aviso informativo não bloqueante para remoção 100%. [pancake-final § Pilar 3 — Defesa em camadas]. Hipótese: label preciso reduz erros acidentais de remoção total por parte de usuários que queriam remover parcialmente.
Pilar 6 — Risk signaling: badge de range no header durante toda a tela de remoção — status da posição visível antes de confirmar a saída. [pancake-final § Pilar 6 — Risk signaling sistêmico]. Hipótese: usuário que vê "Fora da faixa" no header antes de confirmar entende por que a composição de saída é assimétrica.

⚪ Novo

Card de resultado com breakdown explícito: aportado / a retirar / IL / taxas / resultado líquido com caption pedagógica por situação. Não documentado nos relatórios de concorrentes como feature de tela de remoção — Uniswap e Pancake mostram apenas "tokens a receber" sem contexto do aporte. Justificativa: sem esse breakdown, o usuário que saiu com R$ 32.328 de uma posição de R$ 43.390 (mas com R$ 59,80 em taxas) não sabe se perdeu dinheiro ou se o LP foi positivo considerando as taxas. O dado está disponível on-chain; a tela deve apresentá-lo antes do commit — não depois, quando é tarde para revisar. Risco: resultado calculado com dados desatualizados pode criar expectativa errada de R$ X e o usuário recebe R$ Y. Mitigação: timestamp visível + nota de que a composição exata é calculada on-chain. Evidência futura: taxa de abertura do link pedagógico "O que é IL e como ele afeta minha saída?" — indica se o breakdown está claro o suficiente ou se o usuário ainda busca explicação.
Caption pedagógica condicional por resultado (positivo vs negativo). Não documentado nos relatórios. Justificativa: o mesmo framework de "templates conservadores por situação" aplicado em pools-02 (caption do chart) e pools-04 (preview de IL) — aqui aplicado ao resultado de saída. Custo: 2 strings de UI + i18n. Evidência futura: taxa de tickets de suporte sobre "perdi dinheiro no LP" antes e depois desta tela.
Taxas acumuladas incluídas automaticamente na remoção (sem opção de separar). Simplificação deliberada para o target. Justificativa: separar "retirar liquidez" de "coletar taxas" em duas transações é um detalhe arquitetural que o iniciante não precisa gerenciar — incluso automaticamente reduz cognitive load. Risco: avançado que quer coletar taxas mantendo a posição usa pools-08 (já proposta). Evidência futura: % de usuários que chegam em pools-09 com taxas acumuladas > 0 — se alto, confirma que o agrupamento é a decisão certa.

Trade-offs e segunda ordem

Card de resultado com IL em R$ exige cálculo de "valor hipotético hold" — precisa do preço de ambos os tokens no momento do aporte (evento mint on-chain). Se o subgraph não indexou o evento (posição antiga ou migrada), IL = "não disponível para esta posição". Nunca tentar estimar sem dado canônico.
Preview em tempo real conforme o slider muda implica re-cálculo de proporção de saída a cada mudança de percentual. Cálculo é local (proporção linear do valor total), mas o preço dos tokens precisa estar fresco. Oracle stale bloqueia o re-cálculo — exibir aviso de "preço desatualizado" e congelar o preview até reconectar.
"Encerrar posição" vs "Confirmar remoção" como dois labels para o mesmo botão requerem lógica de renderização condicional. Custo de implementação mínimo; valor na clareza semântica do ato.
Caption pedagógica com valores em R$ é string com variáveis numéricas — não é texto estático. Requer Intl.NumberFormat com locale pt-BR. Custo pontual, valor recorrente.
Aviso de remoção total ("Esta ação encerra sua posição permanentemente") adiciona uma linha de texto visível somente no estado 100%. Não bloqueia — é informativo. Custo: mais um estado de renderização condicional.
Back-navigation: "← Voltar para minha posição" retorna para pools-07. Se o usuário apertar o back do browser durante tx pendente, uma tx on-chain pode estar em voo. O botão "Voltar" deve ser escondido ou substituído por "Ver status da transação" quando uma tx foi enviada.

Conflitos de pilar resolvidos

Pilar 4 (educação contextual: mostrar IL com caption pedagógica completa) vs Pilar 5 (mobile-first: tela enxuta, sem scroll excessivo). Resolvido por: card de resultado compacto com 4 linhas + caption de no máximo 2 linhas. Em mobile, o card cabe antes do CTA sticky no rodapé. A caption não tem botão de fechar — é informação em linha, não popup.
Pilar 3 (defesa em camadas: aviso de encerramento total) vs A3 (armadilha: solução pior que o problema — paternalismo). Resolvido por: aviso é informativo inline, não modal bloqueante + confirmação adicional. Usuário lê a informação no caminho natural para o CTA — não precisa fechar um diálogo extra. Pilar 3 implementado como informação disponível, não como barreira.
Pilar 7 (curadoria opinionada: default 100% para quem vem de out-of-range) vs Pilar 2 (default contextual: quem vem de gestão ativa pode querer remoção parcial). Resolvido por default unificado de 100% em ambos os casos: a maioria dos usuários que clica "Remover liquidez" em qualquer contexto quer sair completamente; chips de atalho (25%/50%/75%) e slider ficam evidentes para quem quer parcial. Default serve o caso mais frequente; ajuste é fácil.

Pools — Tela 10 — Reposicionar faixa de preço ("Ajustar faixa")

Função da tela

Ponto de decisão e execução para o LP V3 cuja posição saiu da faixa ou está se aproximando do limite: apresenta a situação atual com custo explícito de reposicionamento (duas transações sequenciais), guia a escolha entre manter, reposicionar ou encerrar, e — quando o usuário opta por reposicionar — entrega o seletor de nova faixa pré-populado com sugestão centrada no preço atual. Foco em intermediário que criou sua primeira posição V3 e recebeu a notificação de pools-06; iniciante que segue o link "Ajustar faixa" de pools-07 como segundo perfil.

Ponto de entrada principal: CTA "Ajustar faixa" em pools-07 (visível quando badge = "Perto do limite" ou "Fora da faixa"). Ponto de entrada secundário: notificação de alerta de faixa ativada em pools-06.

Componentes / elementos

Estrutural (define o paradigma da tela)

Header de identidade da posição (sticky, herdado de pools-07/08/09)
- Par + protocolo + fee + ID: "ETH / USDC · V3 · 0,05% · #123456"
- Breadcrumb: "Ganhar rendimento › Minhas posições › ETH/USDC › Ajustar faixa"
- Badge de status (herdado de pools-07 — contexto que motivou a chegada aqui):
  - 🟡 "Perto do limite" quando preço está dentro de 5% da borda.
  - ⬜ "Fora da faixa" quando preço saiu da faixa.
Mini-chart de contexto (visualização da situação antes da decisão)
- Gráfico de preço dos últimos 7d com dois elementos sobrepostos:
  - Banda cinza sobre a faixa ativa da posição atual (cinza = faixa parada, diferente do verde de pools-07 quando ativa).
  - Linha vertical do preço atual: "Preço atual: 1 ETH = R$ 18.543".
- Label da faixa: "Sua faixa: R$ 16.689 – R$ 20.397".
- Tap-and-stick em mobile: arrastar mostra o preço do candle no ponto.
- Quando fora da faixa: preço atual visivelmente fora da banda cinza — posição fora do rendimento é intuitivamente clara antes de ler qualquer texto.
Card de situação atual (contexto antes da decisão)
- Linha de status: "⬜ Fora da faixa há 3 dias" (ou "🟡 A X% da borda inferior" quando perto do limite).
- Capital atual: "Capital preservado: ≈ R$ 43.390" — âncora emocional: o usuário precisa saber que não perdeu nada antes de decidir.
- Composição atual (dependente do lado de saída):
  - Se preço saiu acima da faixa: "Composição atual: ≈ 100% ETH".
  - Se preço saiu abaixo da faixa: "Composição atual: ≈ 100% USDC".
- Taxas acumuladas (se houver): "+ R$ 59,80 em taxas prontas para coletar."
- Copy pedagógico de baixo: "Sem urgência — sua posição está preservada. Você pode agir quando quiser."

Seletor de decisão (componente central — três opções como cartões-radio)

Opção	Label primário	Consequência	Custo estimado
A — Manter como está	Manter posição	Sem rendimento até o preço retornar à faixa. Capital preservado.	R$ 0 em gas
B — Definir nova faixa	Reposicionar	Remove a posição atual e cria uma nova na faixa escolhida. 2 transações sequenciais.	≈ R$ 16,80 em gas
C — Encerrar posição	Encerrar posição	Retira capital e taxas para a sua carteira. 1 transação.	≈ R$ 5,40 em gas

Default de seleção:
- Chegando via badge "Perto do limite": Opção A pré-selecionada (preço pode voltar sozinho).
- Chegando via badge "Fora da faixa": Opção B pré-selecionada (posição já parou de gerar rendimento).
Opção C redireciona para pools-09 com positionId pré-carregado — reutiliza o fluxo de remoção já especificado.

Seletor de nova faixa (apenas quando Opção B selecionada — componente estrutural condicional)

Versão simplificada de pools-04 (Passo 2 — faixa e valores), sem stepper e sem seleção de par/protocolo (fixos da posição existente):
- Presets de faixa — chips horizontais com tap-target de 44px mínimo:
  - ±5% do preço atual | ±10% | ±20% | Personalizado
  - Default pré-selecionado: ±10% — centrado no preço atual, não na faixa antiga.
  - Para Opção B com posição "perto do limite": preservar a faixa original como sugestão adicional: Manter faixa atual (±10%) com nota "Sua faixa atual ainda pode funcionar se o preço retornar."
- Faixa em preços absolutos: "Nova faixa sugerida: R$ 16.689 – R$ 22.252" (calculada no preset selecionado).
- Mini-visualização de cobertura histórica: barra horizontal mostrando qual % do preço dos últimos 7d estaria dentro da faixa selecionada. Ex: "Esta faixa cobre 82% da variação de preço dos últimos 7 dias." — dado empírico, não projeção.
- Valores a reaportar (pré-populados da posição existente): "Com a mesma quantidade: 1,17 ETH + R$ 21.695 USDC". Link discreto: "Ajustar valores →" — abre seleção de valores como em pools-04.
- Toggle de inversão de ratio: botão ⇄ que inverte a exibição do par (para quando o preço nominal < 0,01 — auto-flip por magnitude herdado do insight do consolidado Pancake).
Card de custo do reposicionamento (apenas quando Opção B selecionada)
- Título: "Custo desta operação"
- Linha 1: "Transação 1 — Remover posição atual: ≈ R$ 8,40 em gas"
- Linha 2: "Transação 2 — Criar nova posição: ≈ R$ 8,40 em gas"
- Total em gas: ≈ R$ 16,80
- Linha adicional: "+ R$ 59,80 em taxas acumuladas retornam para sua carteira na Transação 1."
- Aviso de 2 assinaturas: "Você vai assinar duas vezes na sua carteira — uma para cada transação."
- Timestamp: "Estimativa às 14:32 · atualiza a cada 30s."
- Link pedagógico: "Por que são 2 transações? →" — abre bottom sheet explicando que reposicionamento = remoção + nova posição, impossível como operação única.
CTA principal (sticky rodapé em mobile, inline em desktop)
- Opção A selecionada: "← Voltar para minha posição" (link, sem ação on-chain — apenas navegação de volta para pools-07).
- Opção B selecionada: "Iniciar reposicionamento" — leva para tela de confirmação (mesmo padrão de pools-05 adaptado para reposicionamento: Passo 1 de 2: Remover posição → Passo 2 de 2: Criar nova posição).
- Opção C selecionada: "Encerrar posição" — redireciona para pools-09.

Cosmético (polish, vai depois do estrutural)

Link "← Voltar para minha posição" — retorna para pools-07 sem nenhuma ação on-chain.
Configurações avançadas ▾ (colapsado) — tolerância de variação de preço (slippage) e deadline da transação. Visível apenas quando Opção B selecionada (as configurações são para o par de transações, não para as opções A/C).
Badge pedagógico de contexto — quando chegando via notificação (não via pools-07): frase de orientação "Você recebeu este alerta porque o preço se aproximou da borda da sua faixa."

Regras de negócio

Herança de contexto obrigatória: recebe positionId da URL. Sem contexto, redireciona para pools-01.
Default de opção por status de range: badge "Perto do limite" → Opção A default; badge "Fora da faixa" → Opção B default. A lógica de default respeita o perfil de urgência: perto do limite tem mais tempo, fora da faixa já perdeu rendimento.
Opção C → reuso de pools-09: não duplicar o fluxo de remoção aqui. Opção C é redirecionamento com positionId e contexto (taxas acumuladas, % de remoção = 100%).
Faixa centrada no preço atual como default de Opção B: não centrar na faixa antiga (que já expirou). Faixa sugerida = [preço_atual * (1 - offset), preço_atual * (1 + offset)] para o preset selecionado.
Faixa que não inclui preço atual: aviso informativo inline (não bloqueante) — o usuário pode querer criar uma faixa fora do preço atual se acreditar em reversão de preço. Soberania preservada.
Custo de gas × 2: Opção B exige duas transações sequenciais on-chain (remove do contrato de LP + mint do novo NFT de LP). Não é possível fazer em uma transação — informação crítica que os concorrentes não expõem.
Taxas acumuladas na remoção: incluídas automaticamente na Transação 1, seguindo a regra de pools-09.
Gas stale (> 60s): badge âmbar no card de custo + "Gas pode ter mudado. Estimativa atualizada."
Nova faixa = nova posição: a posição resultante tem um novo positionId (novo NFT de LP). O NFT antigo é queimado na Transação 1.
Preço moveu > 2% durante a seleção: banner não bloqueante no topo do seletor de faixa: "O preço mudou enquanto você revisava. Faixa sugerida atualizada." Recalcula presets automaticamente.

Estados não-triviais

Estado	Comportamento
Loading	Skeleton no mini-chart, card de situação e opções de decisão. Label: "Carregando situação da posição #123456…"
Perto do limite	Badge 🟡. Card de situação mostra "🟡 A 3% da borda inferior da faixa." Opção A default. Chart mostra preço próximo da borda.
Fora da faixa — acima	Badge ⬜. Card: "Composição atual: ≈ 100% ETH." Opção B default.
Fora da faixa — abaixo	Badge ⬜. Card: "Composição atual: ≈ 100% USDC." Opção B default.
Nova faixa não inclui preço atual	Aviso inline abaixo do seletor: "Esta faixa não inclui o preço atual. Sua posição começará fora da faixa imediatamente." Não bloqueante.
Gas stale	Badge âmbar no card de custo + "Gas pode ter mudado. Estimativa atualizada."
Preço moveu > 2% durante revisão	Banner não bloqueante: "O preço mudou enquanto você revisava. Faixa sugerida atualizada."
Opção B → confirmação passo 1	Navega para tela de confirmação de remoção (mesmo padrão de pools-05 com copy de "reposicionamento").
Opção C	Redireciona para pools-09 com `positionId` pré-carregado.
Sem taxas acumuladas	Linha de taxas no card de custo mostra: "Nenhuma taxa acumulada para coletar."
Rede errada	Banner bloqueante: "Você está na rede [X]. Esta posição existe em [Y]. Mude para continuar." Todas as opções desabilitadas.
Wallet desconectada	Banner bloqueante: "Carteira desconectada. Reconecte para continuar." CTA "Conectar carteira".

Microcopy crítico (PT-BR)

Elemento	Texto
Breadcrumb	Ganhar rendimento › Minhas posições › ETH/USDC › Ajustar faixa
Card situação — fora da faixa	⬜ Fora da faixa há 3 dias
Card situação — perto do limite	🟡 A 3% da borda inferior da faixa
Capital preservado	Capital preservado: ≈ R$ 43.390
Composição — preço acima	Composição atual: ≈ 100% ETH
Composição — preço abaixo	Composição atual: ≈ 100% USDC
Taxas acumuladas	+ R$ 59,80 em taxas prontas para coletar.
Copy pedagógico de urgência	Sem urgência — sua posição está preservada. Você pode agir quando quiser.
Opção A — label	Manter posição
Opção A — consequência	Sem rendimento até o preço retornar à faixa. Capital preservado.
Opção A — custo	R$ 0 em gas
Opção B — label	Reposicionar
Opção B — consequência	Remove a posição atual e cria uma nova na faixa escolhida. 2 transações sequenciais.
Opção B — custo	≈ R$ 16,80 em gas
Opção C — label	Encerrar posição
Opção C — consequência	Retira capital e taxas para a sua carteira. 1 transação.
Opção C — custo	≈ R$ 5,40 em gas
Presets de faixa	±5% do preço atual \| ±10% \| ±20% \| Personalizado
Faixa sugerida	Nova faixa sugerida: R$ 16.689 – R$ 22.252
Cobertura histórica	Esta faixa cobre 82% da variação de preço dos últimos 7 dias.
Valores pré-populados	Com a mesma quantidade: 1,17 ETH + R$ 21.695 USDC
Link ajustar valores	Ajustar valores →
Card custo — título	Custo desta operação
Card custo — transação 1	Transação 1 — Remover posição atual: ≈ R$ 8,40 em gas
Card custo — transação 2	Transação 2 — Criar nova posição: ≈ R$ 8,40 em gas
Card custo — total	Total em gas: ≈ R$ 16,80
Card custo — taxas incluídas	+ R$ 59,80 em taxas acumuladas retornam para sua carteira na Transação 1.
Card custo — 2 assinaturas	Você vai assinar duas vezes na sua carteira — uma para cada transação.
Timestamp gas	Estimativa às 14:32 · atualiza a cada 30s.
Link pedagógico 2 transações	Por que são 2 transações? →
Bottom sheet — explicação	Reposicionar exige duas etapas separadas no contrato: primeiro remover a posição atual (queima o NFT antigo), depois criar uma nova posição com a nova faixa (gera um novo NFT). Não é possível "ajustar a faixa" de uma posição existente em V3 — o protocolo não tem essa operação.
CTA Opção A	← Voltar para minha posição
CTA Opção B	Iniciar reposicionamento
CTA Opção C	Encerrar posição
Aviso faixa fora do preço atual	Esta faixa não inclui o preço atual. Sua posição começará fora da faixa imediatamente.
Gas stale	Gas pode ter mudado. Estimativa atualizada.
Preço moveu durante revisão	O preço mudou enquanto você revisava. Faixa sugerida atualizada.
Rede errada	Você está na rede [X]. Esta posição existe em [Y]. Mude para continuar.

Rastreabilidade obrigatória

🟢 Herdado

Sticky de identidade da posição com par + protocolo + fee + badge de status durante toda a tela de decisão. Fonte: [uniswap posicao-populada-01 § Insight 1 — template de identidade persistente] + padrão interno herdado de pools-07, pools-08, pools-09.
Mini-chart tap-and-stick — posição visual relativa ao preço atual é o dado mais importante desta tela; precisa ser acessível em mobile antes de qualquer texto. Fonte: [pancake-final § Pilar 7 — Mobile-first interaction] + [pancake/_consolidado/visualizar-farm.md § Interação mobile tap-and-stick em gráficos].
Gas em R$, nunca em GWEI. Fonte: [pancake-final § Pilar 7 — Localização BR/LatAm como infraestrutura].
Copy pedagógico de baixo urgência ("Sem urgência — capital preservado"): herdado de pools-07 que ensinou o usuário que "capital não está em risco". Fonte: [proposta/pools/pools-07.md § Estado out-of-range — "Capital preservado — sem urgência para agir"].
CTA dinâmico que reflete a opção selecionada: não existe um CTA genérico, cada opção tem um label preciso ("Manter posição" / "Iniciar reposicionamento" / "Encerrar posição"). Fonte: [pancake-final § Pilar 6 — CTA dinâmico + Default contextual].
Configurações avançadas colapsadas (slippage e deadline) — padrão herdado de pools-08 e pools-09. Fonte: [uniswap/_consolidado/nova-posicao.md § Insight — Feedback visual explícito de estado].
Default de opção baseado em urgência (perto do limite → Opção A; fora da faixa → Opção B). Fonte: [pancake-final § Pilar 6 — Default contextual em 4 camadas — contexto do usuário como primeira camada].
Auto-flip de preço por magnitude no seletor de faixa. Fonte: [pancake/_consolidado/visualizar-farm.md § Auto-flip de preço por magnitude].

🔴 Corrige

Custo duplo de reposicionamento nunca exposto pelos concorrentes: Uniswap e Pancake mostram o seletor de nova faixa sem avisar que repositionar é remove + add = 2 transações + 2× gas. O card de custo com breakdown de Transação 1 e Transação 2 + aviso de 2 assinaturas resolve essa lacuna. Fonte: [uniswap-final § Fricção 1 — Léxico de protocolo como UI sem tradução para consequência] (manifesta como "a operação parece trivial sem expor o custo real").
Ausência de contexto de urgência antes da decisão → Card de situação com "capital preservado" + copy "sem urgência" previne que o usuário tome decisão apressada por alarme falso. Fonte: [pancake-final § Fricção 12 — Estados intermediários e empty states sem distinguir 4 cenários].
i18n parcial → Todo copy em PT-BR; R$ com locale; "gas" como único termo técnico sem equivalente PT-BR. Fonte: [pancake-final § Fricção 2 — i18n parcial e inconsistente].
Affordances nivelados para ações de consequência diferente → As três opções têm design diferenciado por consequência: Opção C (encerrar) não tem destaque primário — é a terceira opção com label preciso. Fonte: [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência].

🟡 Captura

Pilar 4 — Transparência financeira total antes do commit: card de custo com breakdown de gas por transação + total antes de qualquer ação. [pancake-final § Pilar 4 — Educação contextual + Transparência financeira]. Hipótese: LP que vê "R$ 16,80 em gas (2 transações)" antes de confirmar toma decisão informada sobre se o custo vale dado o capital parado; LP que não sabe que vai pagar 2× e descobre só na carteira pode cancelar a segunda transação com a posição já removida — situação pior que a original.
Pilar 3 — Defesa em camadas sem paternalismo: link "Por que são 2 transações?" como bottom sheet explícito em vez de tooltip hover-only. [pancake-final § Pilar 2 — Defesa em camadas universal]. Hipótese: LP que entende o mecanismo antes de assinar não cancela a segunda assinatura em pânico.
Pilar 4 — Educação contextual no ponto de decisão: mini-visualização de "cobertura histórica" (% do preço dos últimos 7d dentro da nova faixa) transforma a seleção de faixa de exercício abstrato em dado empírico concreto. [pancake-final § Pilar 4] + [uniswap/_consolidado/pools.md § Sistema pedagógico de métricas DeFi]. Hipótese: LP que vê "esta faixa cobre 82% dos últimos 7 dias" tem mais confiança na escolha que LP que escolhe por intuição.
Pilar 2 — Default contextual: default de opção baseado no status da posição (A para "perto do limite", B para "fora da faixa") reduz a chance de LP conservador repositionar prematuramente. [pancake-final § Pilar 6]. Hipótese: LP "perto do limite" que vê Opção A como default considera que talvez não precise agir agora; o preço pode retornar sem custo de gas.

⚪ Novo

Estrutura de decisão com 3 opções (manter / reposicionar / encerrar) como componente central desta tela. Não documentado nos relatórios como padrão de tela de LP em nenhum concorrente — Uniswap e Pancake levam o usuário direto para o seletor de nova faixa sem a etapa de "você quer mesmo fazer isso?". Justificativa: repositionar não é "ajustar a faixa" (como sugere o label "Ajustar faixa" de pools-07) — é remove + add, com custo real. Apresentar as 3 opções com custo explícito antes de qualquer ação protege o LP iniciante de um gasto duplo de gas por desinformação. Risco: a tela extra adiciona fricção ao LP experiente que sabe o que quer. Mitigação: default de opção por urgência (LP fora da faixa vê Opção B pré-selecionada — um clique direto para confirmação) + "Ajustar valores →" para LP que quer customizar. Evidência futura a coletar: taxa de seleção de cada opção; se Opção A for dominante quando LP está "fora da faixa", o default de opção deve ser recalibrado.
Mini-visualização de cobertura histórica (% do preço dos últimos 7d dentro da faixa selecionada). Não documentado nos relatórios. Justificativa: a única forma de o LP saber se a nova faixa é "boa" é ver se o preço costuma passar por ela — dado disponível on-chain via subgraph. Transforma escolha subjetiva em escolha informada sem adicionar jargão. Risco: janela de 7d pode não ser representativa para pares com volatilidade pontual (ex: ETH durante notícia de macro). Mitigação: tooltip explica a janela: "Baseado nos últimos 7 dias de preço." Evidência futura: correlação entre cobertura histórica alta e posições que ficam in-range por mais tempo.

Trade-offs e segunda ordem

2 transações sequenciais no fluxo de Opção B implicam 2 telas de confirmação em sequência (mesmo padrão de pools-05, duas vezes). Custo de UX real: usuário que sai entre Transação 1 (remoção confirmada) e Transação 2 (nova posição) ficará sem posição ativa. O banner "você pode fechar — Transação 2 ficará disponível quando voltar" precisa existir entre as duas etapas.
Nova faixa = novo positionId (novo NFT de LP). Quem linkava para a posição antiga (pools-06 compartilhamento, notifications) vai perder o link. Sem solução perfeita — avisar o usuário que o positionId vai mudar não é necessário para iniciante, mas pode confundir o avançado que tem scripts monitorando a posição.
Mini-visualização de cobertura histórica exige query de preço histórico (subgraph). Se o subgraph estiver lento ou indisponível, o dado pode não aparecer a tempo. Fallback: esconder a linha de cobertura e manter apenas os presets de faixa — a tela funciona sem o dado histórico, apenas com menor valor pedagógico.
Auto-flip de preço por magnitude (herança do visualizar-farm) precisa ser consistente entre o mini-chart e o seletor de faixa — se o chart mostra em "USDC/ETH" mas o seletor mostra em "ETH/USDC", a faixa em R$ diverge visualmente. Decisão de produto: escolher uma direção de exibição por sessão e manter.
"Ajustar valores →" (para quem quer reaplicar valor diferente do original) abre um sub-fluxo similar a pools-04. Se o usuário ajustar os valores e voltar, o card de custo precisa recalcular gas para o novo valor. Polling de gas precisa reagir à mudança de valor, não apenas à passagem de tempo.
Cobertura de i18n: 3 opções × 2 linhas de texto = 6 strings com variáveis de valores em R$. Mais 2 templates condicionais de mini-visualização. Tudo requer Intl.NumberFormat com locale pt-BR — custo pontual de implementação.

Conflitos de pilar resolvidos

Pilar 2 (default contextual: pré-selecionar Opção B para LP fora da faixa, acelerando a ação) vs A3 (armadilha: paternalismo — não forçar ação cara sem entendimento): resolvido pelo default de opção como pré-seleção, não como ação automática. LP fora da faixa vê Opção B marcada, mas ainda lê o custo antes de confirmar. A pré-seleção acelera o caminho do recorrente sem eliminar a etapa de revisão do iniciante.
Pilar 3 (defesa em camadas: avisar sobre custo duplo) vs Pilar 5 (mobile-first: tela enxuta): resolvido por card de custo condicional (aparece apenas quando Opção B selecionada) e link pedagógico como bottom sheet (não expansão inline que infla a tela). Em mobile, o card de custo aparece abaixo do seletor de faixa e acima do CTA sticky — scrollável, mas visível antes de confirmar.

Pools — Tela 11 — Stake de token único — catálogo e seleção

Função da tela

Porta de entrada do segmento "Stake de token único" — o segundo segmento da seção "Ganhar rendimento" (ao lado de "Pares de liquidez"). O usuário (foco em iniciante conservador que viu o risco de IL nos cartões de pools-01 e escolheu o caminho sem variação de composição) navega por um catálogo de pools de stake de token único com curadoria opinionada, APR sempre decomposto e sem fragmentação por par — cada entrada é um único ativo.

Ponto de entrada: sub-tab "Stake de token único" na hero de pools-01 (segmento primário).

Componentes / elementos

Estrutural (define o paradigma da tela)

Orientação de segmento (bridging copy de pools-01 — não é um novo hero, é continuidade visual)
- Badge contextual: "Stake de token único · Sem variação de composição"
- Uma frase orientadora: "Deposite um token e receba rendimento. O token que você coloca é o que você retira — sem variação de composição."
- Link pedagógico: "Como funciona o stake? →" — abre bottom sheet com explicação de 4 linhas: o que é stake, diferença de LP (sem IL, sem par), risco real (lockup, rendimento em outro token, smart contract).
Filtros (barra horizontal acima da tabela — mesma altura e nível visual entre todos os filtros)
- Buscar token — input sempre visível em desktop ≥ large breakpoint; em mobile, ícone que expande para input em bottom sheet. Placeholder: "Buscar por token (ex: USDC, ETH)."
- Prazo mínimo — seletor com quatro opções: "Todos os prazos | Sem prazo mínimo | Até 7 dias | Mais de 30 dias."
- Recompensa em — chips horizontais: "Todos | Mesmo token | Outro token." Crítico para o target: stake que recompensa em token distinto do depositado tem risco de volatilidade adicional que o iniciante precisa ver explicitamente antes de filtrar.
- Apenas verificados — toggle, default desligado (neutralidade do catálogo mantida; mesmo critério de pools-01 para LP).

Bloco de curadoria (seção topo antes da tabela — análogo aos cartões "Recomendados" de pools-01)

Três cartões horizontais com pré-seleção curada, hierarquizados por risco:

Cartão	Label	Resumo	Quando escolher
Rendimento estável	Rendimento estável	Stablecoins (ex: USDC, USDT). Rendimento mais baixo e previsível — zero variação no token depositado.	Se você quer rendimento sem risco de oscilação no ativo.
Crescer junto	Crescer junto	Token blue-chip: você deposita ETH e recebe mais ETH como rendimento. Rendimento acumula no mesmo ativo que você já tem.	Se você acredita no ativo e quer mais dele.
Rendimento ampliado	Rendimento ampliado	APR mais alto, mas parte do rendimento vem de outro token (ex: deposita USDC, recebe ETH + USDC).	Se você aceita exposição ao token de recompensa para ter APR maior.

Cada cartão mostra: token de exemplo, "Rendimento estimado (7d) ⓘ" com decomposição inline ("Taxas: X% · Incentivos: Y%"), prazo mínimo, recompensa em (ícone do token com label), e uma frase de justificativa de risco conforme o cartão.
CTA por cartão: "Ver opções →" — aplica filtros no catálogo abaixo (não abre nova página, apenas filtra a tabela e faz scroll até ela).
Link de metodologia: "Como classificamos os stakes?" — abre painel com critério de scoring por perfil (mesmo padrão de pools-01 para transparência editorial).

Tabela de pools de stake (componente central)

Colunas (da mais decisora à mais contextual, esquerda para direita):

Coluna	Conteúdo	Notas
Token	Ícone + nome do token	+ badge de rede quando relevante (ex: USDC on Base vs USDC nativo)
Rendimento estimado (7d) ⓘ	APR anualizado com tooltip pedagógico	Tooltip: "Cálculo baseado nos últimos 7 dias. Pode variar com o volume do pool e com o preço do token de recompensa."
Composto por	Decomposição sempre visível: `Taxas: 3,8% · Incentivos: 0,4%`	Em fonte menor, inline embaixo do APR — nunca atrás de hover. Quando incentivos = 0%: exibe só `Taxas: 4,2%`.
Prazo mínimo	`Sem prazo` ou `7 dias` ou `30 dias`	Badge âmbar quando prazo ≥ 30 dias com tooltip: "Saques antes deste prazo podem ter penalidade."
Recompensa em	Ícone + label do token de recompensa	Quando = mesmo token depositado: `Mesmo token ✓`. Quando diferente: ícone + nome + badge ⚠ se token de recompensa não verificado.
TVL	Valor total depositado no pool	Formato PT-BR (R$ 135 M, não $135K)
Sinal	Badges de risco	⚠ amarelo: rendimento > 100% · ⚠ amarelo: lockup ≥ 30 dias · ⚠ vermelho: token de recompensa não verificado

Sort default: Rendimento estimado desc — para stake (diferente de LP), APR é a métrica primária de decisão: não há fragmentação por par, não há TVL inativo problemático como em LP. Sort por APR desc faz sentido aqui. Label visível: "Ordenado por rendimento."
Header de coluna ativo é clicável e muda o sort; sort selecionado persiste por sessão.
Cada linha tem CTA inline: "Ver e depositar →" — navega para pools-12 com o pool pré-carregado.
Sem sub-linhas expansíveis: stake é single-token sem fragmentação de par × rede × fee. Cada linha é uma entrada canônica. Se o mesmo token existir em duas redes (ex: USDC on Ethereum e USDC on Base), aparecem como duas linhas distintas com badge de rede visível na coluna Token.

Sub-tab "Meus stakes" (contextual, com badge de contagem quando ≥ 1)
- Quando wallet conectada com stakes ativos: lista de posições de stake com token, valor atual, rendimento acumulado, e CTA "Gerenciar".
- Badge de contagem no label da sub-tab: "Meus stakes (2)".
- Empty state com wallet conectada sem stakes: jornada estruturada com 2 caminhos: (1) "Ver opções de rendimento estável →" (filtra por Rendimento estável no catálogo); (2) "Ver todas as opções →" (remove filtros, mostra catálogo completo).
- Empty state sem wallet: "Conecte sua carteira para ver seus stakes." + CTA "Conectar carteira".

Cosmético (polish, vai depois do estrutural)

Link "← Ver pares de liquidez" — troca de segmento sem recarregar a página, preservando o contexto da sessão.
Timestamp de dados — rodapé discreto: "Dados em 11:28 · atualiza a cada 30s."
Paginação simples: "Carregar mais" — sem scroll infinito mudo.

Regras de negócio

"Stake de token único" e "Pares de liquidez" são segmentos separados — nunca misturar na mesma tabela. O seletor de segmento em pools-01 determina qual catálogo mostrar.
APR sempre decomposto inline: toda linha da tabela exibe "Taxas: X% · Incentivos: Y%" embaixo do número principal de APR. Não existe APR cru sem decomposição nesta tela. Decisão editorial: quando incentivos = 0%, exibir apenas "Taxas: X%" sem a linha de incentivos (evitar "Incentivos: 0%" como texto vazio).
Sort default por APR desc (diferente de pools-01 para LP, que usa Atividade 24h desc): a lógica é diferente — stake não tem o problema de TVL parado vs ativo que LP tem; APR é diretamente comparável entre pools de stake single-token. Label sempre visível: "Ordenado por rendimento".
Lockup ≥ 30 dias → badge âmbar na coluna Prazo: prazo longo é risco de liquidez não-óbvio para o iniciante. Badge com tooltip explica a penalidade específica (ex: "Saques antes de 30 dias perdem os incentivos acumulados").
Token de recompensa ≠ token depositado → sinalização obrigatória: coluna "Recompensa em" sempre mostra o token de recompensa com seu ícone. Se for diferente do depositado, é informação de primeiro nível — não detalhe escondido.
Filtro "Apenas verificados" afeta tanto o token depositado quanto o token de recompensa — se qualquer um dos dois não for verificado, a linha é filtrada. Copy obrigatório no tooltip do toggle: "Verificado = critérios objetivos do token. Não é garantia de rendimento."
Sub-tab "Meus stakes" depende de wallet conectada — sem wallet, mostra empty state condicional, não skeleton.
Cartões curados (bloco de curadoria) aplicam filtros na tabela quando clicados em "Ver opções →", não redirecionam para nova página. O scroll automático até a tabela sinaliza a aplicação do filtro.

Estados não-triviais

Estado	Comportamento
Loading inicial	Skeleton nos 3 cartões curados + linhas da tabela (5 linhas placeholder refletindo a estrutura final). Label: "Carregando opções de stake…"
Sem wallet conectada	Tabela e catálogo totalmente visíveis. Sub-tab "Meus stakes" com empty state de conexão. Coluna CTA mostra "Conectar carteira para depositar" em hover.
Wallet conectada, sem stakes	Sub-tab "Meus stakes" com empty state de jornada estruturada (2 caminhos).
Busca sem resultados	"Nenhum pool de stake encontrado para '[termo]'. Tente outro token ou limpe os filtros." + link "Limpar filtros".
Filtros sem resultados	"Nenhum pool encontrado com esses filtros. Tente ampliar os critérios." + link "Limpar filtros".
Erro de dados (RPC / subgraph)	Banner não bloqueante: "Dados desatualizados há X minutos. Tentando reconectar…" + CTA "Tentar agora". Tabela exibe última versão em cache com timestamp visível.
Parcial multi-chain	Banner discreto: "Não foi possível carregar stakes de [rede]. Outras redes continuam visíveis."
APR extremo (>100%)	Badge ⚠ amarelo na coluna Sinal com tooltip: "Rendimentos acima de 100% raramente se sustentam. Veja a decomposição e a janela de cálculo antes de depositar."
Lockup com penalidade	Badge âmbar na coluna Prazo + tooltip com o texto exato da penalidade: "Saques antes de 30 dias perdem os incentivos acumulados — taxas são preservadas."
Token de recompensa não verificado	Badge ⚠ vermelho na coluna Sinal + na coluna Recompensa em. Tooltip: "O token de recompensa não passou nos critérios de verificação. Verifique antes de depositar."

Microcopy crítico (PT-BR)

Elemento	Texto
Badge de segmento	Stake de token único · Sem variação de composição
Frase orientadora	Deposite um token e receba rendimento. O token que você coloca é o que você retira — sem variação de composição.
Link pedagógico	Como funciona o stake? →
Bottom sheet — stake vs LP	No stake de token único, você deposita um ativo e recebe rendimento nele. Diferente dos pares de liquidez, não há variação de composição — o token que você depositou é o que você retira. O risco principal é o rendimento vir de um token de recompensa diferente: se esse token cair de preço, o rendimento efetivo pode ser menor que o APR estimado.
Buscar token	Buscar por token (ex: USDC, ETH)
Filtro prazo	Todos os prazos \| Sem prazo mínimo \| Até 7 dias \| Mais de 30 dias
Filtro recompensa	Todos \| Mesmo token \| Outro token
Toggle verificados	Apenas verificados
Tooltip toggle verificados	Verificado = critérios objetivos do token. Não é garantia de rendimento.
Cartão Rendimento estável (justificativa)	Stablecoins têm variação de preço próxima de zero. Bom ponto de partida para rendimento previsível.
Cartão Crescer junto (justificativa)	Deposite ETH e receba mais ETH. Rendimento acumula no ativo que você já tem.
Cartão Rendimento ampliado (justificativa)	APR mais alto, mas parte do rendimento vem de outro token. Avalie o token de recompensa antes de depositar.
CTA do cartão	Ver opções →
Link metodologia	Como classificamos os stakes?
Coluna Rendimento estimado	Rendimento estimado (7d) ⓘ
Tooltip coluna Rendimento	Cálculo baseado nos últimos 7 dias. Pode variar com o volume do pool e com o preço do token de recompensa.
Decomposição — com incentivos	Taxas: 3,8% · Incentivos: 0,4%
Decomposição — sem incentivos	Taxas: 4,2%
Coluna Prazo	Sem prazo
Coluna Prazo — com lockup	30 dias
Badge lockup longo	Tooltip: Saques antes de 30 dias podem ter penalidade.
Coluna Recompensa — mesmo token	Mesmo token ✓
Label sort ativo	Ordenado por rendimento
CTA de linha	Ver e depositar →
Badge ⚠ APR extremo	Rendimentos acima de 100% raramente se sustentam. Veja a decomposição e a janela de cálculo antes de depositar.
Badge ⚠ recompensa não verificada	O token de recompensa não passou nos critérios de verificação. Verifique antes de depositar.
Empty "Meus stakes" sem wallet	Conecte sua carteira para ver seus stakes.
Empty "Meus stakes" wallet conectada	Você ainda não tem stakes ativos. Por onde quer começar?
Caminho 1 do empty	Ver opções de rendimento estável →
Caminho 2 do empty	Ver todas as opções →
Loading	Carregando opções de stake…
Busca sem resultados	Nenhum pool de stake encontrado para '[termo]'. Tente outro token ou limpe os filtros.
Filtros sem resultados	Nenhum pool encontrado com esses filtros. Tente ampliar os critérios.
Link limpar filtros	Limpar filtros
Erro de dados	Dados desatualizados há X minutos. Tentando reconectar…
CTA retry	Tentar agora
Link trocar segmento	← Ver pares de liquidez

Rastreabilidade obrigatória

🟢 Herdado

Três cartões curados por perfil de risco como bloco de curadoria antes do catálogo cru — anti-paradoxo da escolha. Fonte: [proposta/pools/pools-01.md § Bloco "Recomendados" — pool finder por perfil de risco] — herança do padrão interno; aplicado aqui ao segmento de stake com adaptação (3 perfis diferentes: Estável / Crescer junto / Ampliado em vez de Conservador / Moderado / Agressivo).
Empty state de "Meus stakes" como jornada estruturada com 2 caminhos. Fonte: [pancake-final § Insight — Cobertura proativa de estados não-triviais] + [proposta/pools/pools-01.md § Estado — Vazio — wallet conectada, sem posições].
Filtro "Apenas verificados" com tooltip de disclaimer explícito ("verificado ≠ garantia de rendimento"). Fonte: [uniswap/_consolidado/pools.md § Verificação por token em pool — Oportunidade].
Badges de risco na coluna Sinal com os mesmos thresholds de pools-01 (APR > 100% → ⚠ amarelo; token não verificado → ⚠ vermelho) — consistência de signal trail entre catálogo LP e catálogo de stake. Fonte: [pancake-final § Pilar 3 — Risk signaling sistêmico] + [uniswap/_consolidado/pools.md § Outliers sem sinalização].
Sort default com label visível ("Ordenado por rendimento"). Fonte: [proposta/pools/pools-01.md § Sort default — "Ordenado por atividade"] — herança do princípio de sort nomeado; aqui adaptado para stake (rendimento em vez de atividade).
CTA desabilitado com label contextual em linhas (hover mostra "Conectar carteira para depositar" em vez de CTA cinza mudo). Fonte: [pancake-final § Pilar 6 — CTA dinâmico].
Timestamp de dados no rodapé. Fonte: [uniswap/_consolidado/visualizar-pool.md § Fricção — Métricas vivas sem âncora de snapshot].

🔴 Corrige

APR agregado sem decomposição visible: Pancake tem a decomposição (Farm + Taxa de LP) mas esconde atrás de hover. Kotai expõe inline sempre como linha secundária abaixo do número principal. [pancake/_consolidado/visualizar-farm.md § APR opaco / decomposição escondida] + [pancake/_consolidado/visualizar-farm.md § Oportunidade — APR decomposto visível por default].
Token de recompensa escondido ou não-sinalizado: DEXs atuais listam stake sem deixar claro que o APR pode vir de um token distinto do depositado. Coluna "Recompensa em" como coluna de primeiro nível torna essa informação inescapável. [pancake-final § Fricção 5 — Risk signaling ausente em pontos de decisão de alto custo financeiro].
Léxico técnico como vocabulário primário ("Syrup Pools", "vCAKE", "CLAMM") → "Stake de token único" como label de segmento + nomes funcionais nos cartões ("Rendimento estável", "Crescer junto"). [pancake-final § Fricção 1 — Léxico de protocolo e infraestrutura como vocabulário primário de UI].
i18n parcial → Todo copy em PT-BR; R$ com locale; termos técnicos (APR, TVL) preservados apenas quando não há equivalente PT-BR. [pancake-final § Fricção 2 — i18n parcial e inconsistente].
Lockup period não visível antes do clique: concorrentes exibem o prazo mínimo apenas dentro da página de detalhes do stake — não na listagem. Coluna "Prazo mínimo" como coluna de primeiro nível expõe o dado antes do CTA. [pancake-final § Fricção 11 — Densidade técnica avançada exposta no fluxo padrão] (inversão: dado crítico que estava escondido agora fica visível).

🟡 Captura

Pilar 4 — APR decomposto sempre visível: "Taxas: X% · Incentivos: Y%" inline embaixo do APR — o dado mais importante para a decisão de stake está na tela, não atrás de hover. [pancake-final § Pilar 4 — Educação contextual + Transparência financeira] + [pancake/_consolidado/visualizar-farm.md § Oportunidade — APR decomposto visível por default]. Hipótese: usuário que vê "Incentivos: 0,4%" antes de depositar entende que a maior parte do rendimento é taxa orgânica, não incentivo temporário — calibra expectativa antes do commit.
Pilar 6 — Risk signaling sistêmico na listagem: badge ⚠ de token de recompensa não verificado na coluna Sinal e na coluna Recompensa em — dupla sinalização para risco específico de stake. [pancake-final § Pilar 3 — Risk signaling sistêmico]. Hipótese: iniciante que vê badge ⚠ vermelho no token de recompensa antes de clicar tem mais chance de investigar o token de recompensa antes de depositar.
Pilar 7 — Curadoria opinionada: três cartões curados com perfil de risco explícito e metodologia auditável substituem o catálogo cru como ponto de entrada. [pancake-final § Pilar 5 — Curadoria opinionada por default + Modo avançado opt-in]. Hipótese: iniciante que clica em "Ver opções de rendimento estável" chega no catálogo já filtrado por risco correspondente ao seu perfil — menos chance de se perder em opções de APR extremo.
Pilar 1 — Naming system: "Stake de token único", "Rendimento estável", "Crescer junto", "Rendimento ampliado" como labels de UI. "Syrup Pool", "vCAKE", "Fixed APR" como termos técnicos em tooltip ou secondary label. [pancake-final § Pilar 1 — Naming system]. Hipótese: iniciante que vê "Rendimento estável — deposite stablecoins" toma a decisão certa mais rápido que iniciante que vê "Syrup Pool — vCAKE staking".

⚪ Novo

Filtro "Recompensa em" (Todos / Mesmo token / Outro token) como filtro de primeiro nível. Não documentado nos relatórios de concorrentes como filtro disponível em listagens de stake. Justificativa: staking que paga em token diferente do depositado tem perfil de risco distinto (risco de preço do token de recompensa somado ao risco do token depositado); o iniciante que deposita USDC esperando receber USDC pode se surpreender ao receber um token volátil. Filtro de primeiro nível torna a distinção acessível antes de entrar nos detalhes de cada pool. Risco: reduz a descoberta de pools com rendimento em outro token por usuários que poderiam estar abertos a esse risco. Mitigação: default "Todos" (sem filtro aplicado); o filtro é opt-in, não padrão. Evidência futura: taxa de uso do filtro "Mesmo token" — se alta, confirma que a distinção é crítica para a decisão; se baixa, pode ser rebaixado para "Mais filtros".
Coluna "Recompensa em" como coluna de primeiro nível na tabela (não detalhe dentro da linha). Não documentado nos relatórios como padrão de catálogo de stake. Justificativa: a identidade do token de recompensa é critério de decisão tão crítico quanto o APR — esconder em detalhe é A5 (inventar complexidade desnecessária não, mas esconder informação necessária sim). Risco: infla a tabela com uma coluna extra. Mitigação: em mobile, coluna "Recompensa em" aparece comprimida como ícone + label curto; em desktop tem espaço suficiente.

Criar Pool — Tela 03: Revisão e confirmação da posição

1. Função da tela

Apresenta ao usuário um resumo completo e imutável de todos os parâmetros configurados, o custo total da operação com breakdown, e a confirmação antes da assinatura da carteira — garantindo que o usuário sabe exatamente o que vai acontecer antes de se comprometer. Foco: iniciante (prioridade máxima nesta tela — é o último ponto de proteção antes de uma ação irreversível).

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

2.1 Header do resumo da posição Bloco no topo com:

Par de tokens com ícones lado a lado (Token A / Token B)
Modo de provisão em linguagem de benefício: "Simples — passiva" / "Concentrada — faixa [mín]–[máx]" / "Programável — [nome do hook]"
Rede de destino com badge da rede (não apenas texto — convenção visual)
Fee tier (apenas para Concentrada/Programável): "Taxa do pool: X%" com tooltip

2.2 Resumo de aporte Dois itens de linha — um por token:

Ícone + símbolo + valor com separador decimal PT-BR
Equivalente em BRL ao lado (ex: "0,05 ETH — R$ 892,50")
Linha de total: "Total a depositar: R$ X.XXX,XX" (soma dos dois tokens em BRL)

2.3 Resumo financeiro (componente mais crítico desta tela — implementa transparência financeira total)

Dividido em dois blocos visuais com separador explícito entre eles. A separação é estrutural: a taxa do pool é rendimento futuro esperado (não custo); o gas é o único custo real desta operação; o aporte é capital recuperável. Misturar os três numa "lista de custos" é o framing errado que Pancake e Uniswap fazem — a Kotai separa os três com headers visuais.

Bloco A — O que você vai ganhar:

Item	Valor	Tooltip
Taxa do pool	X% por swap dentro da sua faixa	"Porcentagem que você recebe de cada swap realizado dentro da sua posição. Valor futuro — não pago agora, não cobrado pela Kotai."

Bloco B — O que você paga agora (para criar a posição):

Item	Valor	Tooltip
Gas (taxa de rede)	R$ X,XX (≈ X ETH/BNB)	"Custo cobrado pela rede para processar a transação. Pode variar conforme congestionamento. Você paga mesmo se a transação falhar."

Linha de total em destaque: "Você paga agora: R$ [gas]" — em fonte maior, abaixo do Bloco B. Nota complementar abaixo do total: "O aporte de R$ X.XXX,XX vai para a posição e pode ser retirado depois — não é custo." O framing em três camadas (taxa que você ganha / aporte recuperável / gas pago agora) previne os dois erros mais comuns do iniciante BR: ler a taxa do pool como custo pago à plataforma, e interpretar o aporte como saída irrecuperável de dinheiro.

2.4 Parâmetros de proteção Linha compacta: "Slippage máximo: [valor]% | Transação expira após: 30 minutos"

2.5 Aviso de pool novo (condicional — apenas quando pool é criado pela primeira vez) Banner destacado (fundo azul, não vermelho — informa, não alarma): "Você será o primeiro a fornecer liquidez neste pool. O preço inicial que você definiu ([valor]) ficará registrado na blockchain. Confirme que este preço reflete o valor de mercado atual."

Para este caso, o CTA muda (ver RN-20).

2.6 Warning de modo Programável com hook ativo (condicional — apenas para V4 com hook selecionado) Banner amarelo acima do CTA: "Este modo usa lógica personalizada (hook) de terceiros. A Kotai não audita hooks externos. Verifique a origem do hook antes de confirmar." Segue o padrão Tier 2 (perda de proteção, não perda direta) — modal de confirmação com consequência explicada, sem type-to-confirm completo (que é reservado para Tier 1).

2.7 CTA de confirmação (principal) Botão primário: "Criar minha posição"

Cor: azul primário padrão (não verde — verde é reservado para ações neutras; esta ação é commit financeiro)
Botão "Voltar e editar" abaixo como secundário cinza

Após clique no CTA: transição para estados de interação com a carteira (ver seção 4).

Cosméticos (polish posterior)

2.8 Stepper — Etapa 2 ativa: "Confirmar". Etapa 1 marcada como concluída. 2.9 Breadcrumb — "Ganhar rendimento / Criar posição / Confirmar" 2.10 Link "Ver no explorador de blocos" — fica disponível apenas após a transação ser submetida com hash conhecido.

3. Regras de negócio

RN-20 — CTA para pool novo: barreira extra de consciência. Quando o pool é novo: o CTA muda para "Confirmar e criar pool". Um checkbox inline aparece acima do CTA: "Entendo que estou criando um pool novo e que o preço inicial que defini pode ser corrigido por arbitragem." O checkbox deve ser marcado manualmente pelo usuário para habilitar o CTA. Este não é type-to-confirm (Tier 1) porque a perda esperada é limitada ao slippage de arbitragem, não à perda total do capital. Mas é uma barreira de consciência (Tier 2) explícita.

RN-21 — CTA para hook ativo (modo Programável). Quando hook de terceiro selecionado: o CTA muda para "Confirmar com hook ativo". Banner de aviso Tier 2 aparece. O botão fica habilitado sem type-to-confirm — o usuário escolheu ativamente o modo Programável na Tela 01, o que já foi uma decisão consciente. Redundância excessiva seria A3.

RN-22 — Imutabilidade dos parâmetros nesta tela. Nenhum campo é editável na Tela 03. Todos os valores são somente leitura. O único caminho de edição é clicar em "Voltar e editar" (que retorna à Tela 02 com todos os campos preservados — sem reset). Isso previne o caso de Uniswap onde o valor pode ser reescrito silenciosamente ao editar na tela de review.

RN-23 — Gas estimado: atualização e validade. O gas estimado é buscado na chegada à Tela 03 (não na Tela 02). Validade do estimate: 30 segundos. Após 30s: badge "Gas estimado desatualizado" + botão "Atualizar estimativa" inline. Se o gas aumentou > 20% entre estimate e submissão: aviso no estado de aguardando carteira "O gas subiu. Valor real pode ser maior." O CTA não é bloqueado — o usuário decide na carteira.

RN-24 — Equivalente em BRL: âncora de preço. O equivalente em BRL usa cotação de mercado no momento do carregamento da Tela 03 com timestamp: "Cotação em [HH:MM]". Não atualiza em tempo real para não gerar ansiedade de "o valor está mudando enquanto leio". Botão "Atualizar cotação" disponível se o usuário quiser.

RN-25 — Interação com a carteira: polling e estados. Após clique em "Criar minha posição":

Modal de carteira dispara (ou popup para EOA)
Estado "Aguardando confirmação da carteira" com spinner e instrução visível
Se popup não aparecer em 3s: "Não viu o popup? [Reabrir popup] | [Mudou de ideia? Cancelar]"
Após confirmação na carteira: estado "Transação enviada" com hash + link para explorador
Polling a cada 3s (ou via event listener se disponível) com atualização de status
Sucesso: tela de confirmação (ver estado de sucesso abaixo)
Falha: estado de erro com causa explícita + ação de recuperação

RN-26 — Persistência de status cross-sessão. Se o usuário fechar o app após submeter a transação mas antes da confirmação: ao reabrir, banner no header "Você tem uma transação em andamento: criar posição [Token A/Token B]. [Ver status]." Polling continua em background se o app for PWA com service worker.

4. Estados não-triviais

Estado normal (revisão ativa): Tela completa com todos os parâmetros, breakdown de custo, CTA ativo. Gas estimado com timestamp.

Pool novo — checkbox obrigatório: Banner azul + checkbox não marcado + CTA disabled até marcar. Ao marcar: CTA "Confirmar e criar pool" habilita (azul primário).

Hook ativo (Programável): Banner amarelo acima do CTA. Botão "Criar minha posição" com sublabel "usando hook [nome]". Nenhum bloqueio adicional.

Gas estimado expirado: Badge inline "Estimativa de gas desatualizada" + botão "Atualizar" ao lado. CTA continua ativo (o usuário pode prosseguir com estimativa antiga — só precisa ser informado).

Aguardando abertura do popup da carteira (estado 1–3s): Overlay sobre o modal com spinner + "Aguardando sua carteira...". Após 3s sem popup detectado: "Não viu o popup? [Reabrir popup] | [Cancelar e voltar]". Timer visual de 30s no spinner — após 30s sem interação: "Parece que a carteira não respondeu. [Tentar de novo] | [Cancelar]."

Aguardando confirmação na blockchain (após assinar na carteira): Tela de status:

Hash da transação truncado + ícone de copy + link para explorador
Spinner com label "Criando sua posição..."
Estimativa de tempo: "Geralmente leva menos de 1 minuto"
CTA secundário: "Ir para Início — seu status fica visível no menu" (não force o usuário a esperar na tela)

Sucesso: Tela de confirmação:

Ícone de check verde grande
Título: "Posição criada!"
Resumo compacto: par + modo + valores depositados + equivalente em BRL
Dois CTAs: "Ver minha posição" (primário) / "Criar outra posição" (secundário)
Link para explorador de blocos com hash

Falha na transação (rejeitada pela rede): Mensagem: "Sua transação não foi processada." + causa específica se disponível:

"Slippage excedido — o preço mudou antes da execução. [Tentar de novo com slippage maior] | [Voltar e ajustar]"
"Gas insuficiente. [Tentar de novo com gas mais alto]"
"Aprovação de token pendente. [Aprovar [Token] primeiro]"
Genérico: "A rede rejeitou a transação. Código: [código]. [Ver detalhes] | [Tentar de novo]" Não diz "Erro desconhecido" sem oferecer próximo passo.

Rejeição na carteira (usuário recusou o popup): Mensagem: "Você cancelou a assinatura na carteira." + CTA: "Tentar de novo" (primário) / "Voltar e editar" (secundário).

Carteira desconectada durante a revisão: Banner no topo: "Carteira desconectada. [Reconectar]" com nome da wallet e botão. Tela de revisão permanece visível (parâmetros preservados). CTA bloqueado até reconexão.

5. Microcopy crítico

Título da tela: "Revisar posição"

Subtítulo do header do resumo: "Verifique tudo antes de criar sua posição. Esta ação não pode ser desfeita."

Linha de total do aporte: "Total a depositar: R$ X.XXX,XX" (nota: é o capital que você coloca na posição, não o custo)

Resumo financeiro:

Bloco A — O que você vai ganhar:

"Taxa do pool: X% por swap" — "Porcentagem que você recebe de cada swap dentro da sua posição. Valor futuro — não cobrado agora, não cobrado pela Kotai."

Bloco B — O que você paga agora:

"Gas (taxa de rede): R$ X,XX" — "Custo de processamento da rede. Cotação em [HH:MM]. Você paga mesmo se a transação falhar."
Separador visual + linha de total em destaque
"Você paga agora: R$ X,XX" (apenas gas) — em fonte maior
Nota: "O aporte de R$ X.XXX,XX vai para a posição — não é custo."

Linha de proteção: "Slippage máximo: [X]% · Transação expira após: 30 minutos"

Banner de pool novo: "Você será o primeiro a fornecer liquidez neste pool. O preço inicial que você definiu ([valor]) ficará registrado na blockchain. Confirme que este preço reflete o valor de mercado atual."

Checkbox de pool novo: "Entendo que estou criando um pool novo e que o preço inicial pode ser corrigido por arbitragem imediatamente."

Banner de hook ativo: "Este modo usa lógica personalizada (hook) de terceiros. A Kotai não audita hooks externos. Verifique a origem do hook antes de confirmar."

CTAs:

Principal (padrão): "Criar minha posição"
Principal (pool novo): "Confirmar e criar pool"
Principal (hook ativo): "Criar minha posição com hook ativo"
Secundário: "Voltar e editar"

Estados de carteira:

Aguardando: "Aguardando sua carteira... Confirme o popup."
Popup não apareceu: "Não viu o popup? [Reabrir popup] | [Cancelar e voltar]"
Timeout: "Parece que a carteira não respondeu. [Tentar de novo] | [Cancelar]"
Processando (pós-assinatura): "Criando sua posição na rede..."
ETA: "Geralmente leva menos de 1 minuto."

Sucesso:

Título: "Posição criada!"
Subtítulo: "Sua posição de [Token A]/[Token B] já está ativa."
CTA primário: "Ver minha posição"
CTA secundário: "Criar outra posição"

Falhas:

Slippage: "Slippage excedido — o preço mudou antes da execução."
- CTA: "Tentar de novo com slippage maior" / "Voltar e ajustar"
Gas: "Gas insuficiente para processar a transação."
- CTA: "Tentar de novo com gas mais alto"
Aprovação pendente: "Você precisa aprovar o uso de [Token] antes de criar a posição."
- CTA: "Aprovar [Token] primeiro"
Cancelado na carteira: "Você cancelou a assinatura na carteira."
- CTA: "Tentar de novo" / "Voltar e editar"

6. Rastreabilidade obrigatória

🟢 Herdado

Imutabilidade dos parâmetros na tela de revisão — tela de review como estado de conferência, não de edição; evita o caso de Uniswap onde valores podem ser reescritos silenciosamente. [uniswap-nova-posicao § Observações adicionais — Mudança silenciosa de valores em momento crítico]
Botão CTA muda de label conforme estado do fluxo — "Criar minha posição" → "Aguardando carteira..." → feedback de status; label reflete o estado, não é genérico. [uniswap-nova-posicao § 🟢 Feedback visual explícito de estado] + [pancake-final § Pilar 6 — CTA dinâmico]
Equivalente em moeda local ao lado de todo token amount — BRL ao lado de cada linha de token. [uniswap-final § 🟢 Múltiplas representações do mesmo dado]
Copy preventiva que declara o que vai acontecer — "Esta ação não pode ser desfeita" no subtítulo; "Gas estimado: você paga mesmo se a transação falhar" como tooltip do gas. [uniswap-final § 🟢 Copy preventiva que declara o porquê]
Estado de erro com causa específica + ação de recuperação — cada falha tem causa + próximo passo em vez de "Erro desconhecido". [uniswap-final § 🟢 Estados como instrução acionável]
MEV protection como informação visível no ponto de decisão — warning de slippage alto + chip "Usar MEV protection" (se disponível) em vez de setting enterrado. [pancake-final § 🟢 Transparência proativa antes do CTA — MEV protection como chip persistente]

🔴 Corrige

Ausência de rota de retorno após handoff à carteira — estados explícitos de "popup não apareceu" com "Reabrir popup" + "Cancelar" + timeout visual. [pancake-final § Fricção 8 — Abandono em handoff] + [uniswap-final § Fricção 9 — Handoff a provedor externo sem rastro]
Banner cross-sell de pools com APR maior na tela de review (Uniswap) — a Kotai não exibe cross-promo na tela de confirmação; foco único na ação do usuário. [uniswap-final § Fricção 5 — Cross-promo do ecossistema sobrepõe a tarefa]
CTAs em contexto de risco em verde primário — CTA de confirmação financeira em azul primário (não verde); destrutivo em cor de alerta; "Voltar e editar" como secundário neutro. [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência — "Turn On Expert Mode" verde]
Fee total opaca — gas escondido ou misturado com taxa — linha "Você paga agora: R$ X,XX (gas)" separada visualmente do aporte total; breakdown por componente. [pancake-final § 🟢 Transparência proativa antes do CTA — fee total antes do botão] + [uniswap-final § Fricção 6 — Métricas DeFi sem decomposição]
i18n parcial — nenhuma string em inglês nesta tela; gas em BRL + ETH ao mesmo tempo; tooltip de gas em PT-BR. [pancake-final § Fricção 2] + [uniswap-final § Fricção 8]

🟡 Captura

Transparência financeira completa antes do commit — breakdown "Taxa do pool / Gas / Você paga agora" com framing que distingue aporte (capital recuperável) de gas (custo de operação). [pancake-final § Pilar 4 — Educação contextual + transparência financeira ativa]
Persistência de status cross-sessão para transação em andamento — banner no header ao reabrir o app com transação pendente. [pancake-final § Fricção 8 — Abandono em handoff] — a Kotai vai além do diagnóstico: resolve com persistência de estado cross-sessão.
Modal de review com framing prospectivo — "Esta ação não pode ser desfeita" + checkbox para pool novo + aviso de hook como antecipação das consequências, não confirmação passiva. [uniswap-final § Pilar 5 — Modal de review prospectivo com cenários] (subset — cenários completos são escopo de iteração futura)

⚪ Novo

Checkbox de consciência para criação de pool novo (Tier 2): a distinção entre Tier 1 (type-to-confirm) e Tier 2 (checkbox) para pool novo é uma aplicação da hierarquia de tiers proposta no Pilar 2 dos relatórios finais, mas a calibração específica de que "criar pool novo = Tier 2, não Tier 1" não tem evidência direta nos consolidados. Justificativa: a perda esperada de uma criação de pool mal calibrada é limitada ao slippage de arbitragem nos primeiros blocos (não ao capital total — o usuário pode retirar depois). Um type-to-confirm seria A3 — solução pior que o problema. Evidência a coletar: taxa de abandono no checkbox vs taxa de criação de pools com preço inicial muito desviado do mercado. Se a taxa de desvio for alta mesmo com checkbox, upgrade para type-to-confirm na iteração seguinte.
Framing tríplice: "Taxa que você ganha / Aporte recuperável / Você paga agora": a separação visual entre os três elementos — taxa do pool (rendimento futuro esperado), aporte (capital que entra na posição e pode ser retirado) e gas (único custo real da operação agora) — não tem origem direta nos consolidados. Ambos os concorrentes misturam taxa, aporte e gas em uma única seção de "custo" ou "resumo de transação", o que para o iniciante BR cria dois erros simultâneos: (a) interpretar a taxa do pool como custo pago à plataforma; (b) interpretar o aporte como saída irrecuperável de dinheiro. O design system deve impedir o agrupamento desses três elementos num único componente sem headers visuais que distingam a natureza de cada um. Justificativa: iniciante BR vindo de CEX associa "qualquer item numa lista de custos" a "sai da minha conta agora". Separar os três blocos com labels explícitos ("O que você vai ganhar / O que você paga agora") é o único framing que previne os dois erros ao mesmo tempo. Evidência a coletar: testes de usabilidade com iniciante — "quanto você vai pagar para criar esta posição?" e "quanto você vai ganhar?"; verificar se as respostas distinguem corretamente gas de taxa do pool, e aporte de custo.

7. Trade-offs e segunda ordem

Imutabilidade na Tela 03: o usuário não pode editar nada nesta tela — qualquer mudança exige "Voltar e editar". Em Tela 02, se o usuário mudou valores e voltou à Tela 03, todos os parâmetros são recalculados (gas estimado, equivalente BRL, breakdown). Custo: uma navegação extra por edição. Benefício: elimina o risco de edição silenciosa de valores críticos.

Gas estimado com TTL de 30s: em redes congestionadas, o gas pode subir significativamente em 30s. A Kotai não bloqueia o CTA por gas desatualizado — informa e deixa o usuário decidir. Risco: usuário confirma com estimativa de R$ 2,50 e paga R$ 8,00 de gas. Mitigação: o warning de expiração é proeminente; o tooltip do gas já diz "pode variar conforme congestionamento". Alternativa considerada e rejeitada: bloquear CTA até atualizar — criaria tensão de "não consigo confirmar" em redes ocupadas. A3.

Persistência de estado cross-sessão: requer storage local (localStorage/IndexedDB) ou backend de estado de transação. Se o produto não tem backend de usuário, a persistência fica só no dispositivo — banner não aparece em outro dispositivo. Aceitável para MVP; expandível com backend na próxima iteração.

Polling de confirmação: polling a cada 3s pode ser substituído por WebSocket ou event listener em RPC que suporte eth_subscribe. Em produção, WebSocket é preferível (menos carga de rede, menor latência de confirmação). Polling de 3s é fallback garantido para RPCs que não suportam subscribe.

Checkbox para pool novo: adiciona uma fricção Tier 2 que não existe em nenhum concorrente. Risco de A3 (solução pior que o problema) se usada para casos de baixo risco. Mitigação: o checkbox é restrito exclusivamente à criação de pools novos — não ao fluxo padrão de adicionar liquidez a pool existente. Esse escopo cirúrgico preserva a experiência do caso 90% e protege apenas o caso de alto risco.

Copy de transparência financeira: "Esta ação não pode ser desfeita" como subtítulo permanente da tela pode criar ansiedade excessiva para usuários que já estão confortáveis com DEX. Risco de A3 (friction desnecessária para intermediário). Mitigação: testar se o subtítulo causa mais abandonos do que protege — se sim, mover para tooltip ou retirar em futuras iterações.

Criar Pool — Tela 04: Aprovação de tokens

1. Função da tela

Permite que o usuário autorize o contrato de LP a movimentar os tokens selecionados antes de criar a posição, com transparência sobre o que cada aprovação significa, o custo de gas e o tipo de aprovação escolhida. Foco: iniciante (máxima proteção e vocabulário acessível), intermediário (eficiência com controle).

Contexto narrativo: esta tela aparece entre a Tela 02 (configuração) e a Tela 03 (revisão), apenas quando um ou ambos os tokens ainda não têm aprovação suficiente para o valor de aporte configurado. Quando ambos os tokens já estão aprovados, a tela é pulada silenciosamente e o stepper em Tela 03 exibe apenas dois passos ("Configurar → Confirmar").

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

2.1 Header de contexto de aprovação

Título: "Autorizar seus tokens" Subtítulo: "Antes de criar sua posição, o protocolo precisa da sua autorização para movimentar os tokens escolhidos. Isso é um passo de segurança padrão e acontece uma vez por token."

Badge de passo no stepper expandido: "Passo 2 de 3: Autorização" (entre Configurar e Confirmar).

2.2 Lista de aprovações necessárias

Uma linha por token que precisa de aprovação. Tokens aprovados não aparecem na lista (eliminar ruído). Cada linha contém:

Ícone + símbolo do token
Label: "[Token] precisa de autorização"
Chip de status: "Pendente" (cinza) | "Autorizando..." (spinner) | "Autorizado ✓" (verde)
Seletor de tipo de aprovação expandível (ver 2.3)
Botão de ação: "Autorizar [Token]" — botão secundário; habilitado sequencialmente (Token B fica bloqueado enquanto Token A está pendente)

2.3 Seletor de tipo de aprovação (expandível por token, dentro da linha)

Dois chips horizontais:

Chip A: "Apenas para esta posição ([valor exato] [Token])" — padrão, selecionado por default, sem badge adicional
Chip B: "Para todas as transações futuras (Ilimitado)" — badge ⚠, tooltip explicativo ao tocar

Chip "Ilimitado" — tooltip: "Autorização ilimitada permite que o protocolo movimente qualquer quantidade deste token em suas transações futuras, sem nova confirmação. Conveniente, mas você concede mais acesso do que o necessário agora. Você pode revogar em Gerenciar aprovações."

Se o token suporta EIP-2612 (Permit2): aparece terceira opção em destaque, "Autorizar via assinatura (sem gas)" com badge verde "Recomendado — sem custo de gas". Tooltip: "Assinatura off-chain — não é uma transação de rede, não cobra gas. Funciona como uma autorização temporária e segura."

2.4 Estimativa de gas por aprovação

Linha abaixo do seletor de tipo: "Custo desta autorização: aprox. R$ X,XX" Tooltip: "Gas de rede. Você paga este custo mesmo que não crie a posição depois. Se usar autorização via assinatura (quando disponível), esse custo não existe."

2.5 CTA de avanço

Botão primário: "Continuar para revisão"

Disabled enquanto há tokens pendentes de aprovação: "Autorizar tokens primeiro"
Enabled apenas quando todos os tokens exibidos na lista têm status "Autorizado ✓"

Cosméticos (polish posterior)

2.6 Stepper de progresso — Expandido para 3 etapas: "1 Configurar" (concluído, ✓) → "2 Autorizar" (ativa) → "3 Confirmar". Recolhe para 2 etapas em Tela 03 quando não há aprovações pendentes (pula a etapa de autorização silenciosamente).

2.7 Breadcrumb — "Ganhar rendimento / Criar posição / Autorizar tokens"

3. Regras de negócio

RN-27 — Pulo automático quando todos os tokens já estão aprovados. Ao avançar de Tela 02, o sistema verifica o estado de aprovação de ambos os tokens para o valor de aporte configurado. Se ambos têm aprovação suficiente: avança diretamente para Tela 03 sem exibir Tela 04. O stepper em Tela 03 retorna ao formato de 2 etapas ("Configurar → Confirmar"). Nenhuma mensagem de "passo ignorado" é necessária.

RN-28 — Aprovação insuficiente vs. ausente. Se o token tem aprovação mas o valor aprovado é menor que o valor de aporte atual: status exibido como "Aprovação insuficiente" (não "Pendente"). O botão "Autorizar" aprova exatamente o delta faltante (modo "Apenas para esta posição") ou o total (modo "Ilimitado" — com modal Tier 2 descrito em RN-31).

RN-29 — Sequencialidade de aprovações. Token A deve ser aprovado antes do botão de Token B ser habilitado. Isso previne a submissão paralela de duas transações de aprovação que competiriam por nonce na carteira, causando confusão sobre "qual popup estou confirmando". A sequência é fixada na UI independentemente do suporte técnico da rede a aprovações simultâneas — a simplicity protege o iniciante.

RN-30 — Permit2 / aprovação sem gas (EIP-2612). Para tokens que suportam EIP-2612: o chip "Autorizar via assinatura (sem gas)" é exibido com badge verde "Recomendado". O clique dispara apenas uma assinatura de mensagem na carteira (não uma transação on-chain). Após a assinatura: status muda para "Autorizado ✓" sem polling de blockchain. Para tokens sem suporte a EIP-2612: esse chip não aparece; apenas "Exata" e "Ilimitado" disponíveis.

RN-31 — Aprovação ilimitada: barreira de consciência Tier 2. Ao selecionar o chip "Ilimitado" e clicar em "Autorizar [Token]": modal de consciência (não type-to-confirm — é Tier 2, não Tier 1, porque o usuário pode revogar e a perda não é imediata). Corpo do modal: "Ao aprovar sem limite, você autoriza que o protocolo da Kotai movimente qualquer quantidade de [Token] da sua carteira em transações futuras, sem nova confirmação. Você pode revogar esta autorização a qualquer momento em Gerenciar aprovações." CTA primário: "Usar valor exato desta posição" (azul — caminho mais seguro como ação padrão). CTA secundário: "Confirmar aprovação ilimitada" (laranja — cor de alerta; ação de risco não recebe cor primária). [pancake-final § Pilar 2 — CTAs em contexto de risco invertidos] + [uniswap-final § Fricção 7 — Affordances nivelados para ações de risco diferente]

RN-32 — Polling de confirmação de aprovação on-chain. Após assinatura na carteira (para aprovações que geram transação): polling a cada 2s. Status muda para "Autorizando..." com spinner. Após confirmação on-chain: status muda para "Autorizado ✓" e o próximo token (ou o CTA de avanço) é habilitado. Timeout de 60s sem confirmação: "A autorização está demorando mais que o esperado. [Verificar no explorador ▸] | [Tentar de novo]".

RN-33 — Persistência de aprovação parcial entre sessões. Se o usuário aprovar Token A e sair do fluxo antes de aprovar Token B: ao retornar via URL parametrizada, a tela reabre com Token A exibindo status "Autorizado ✓" (lido do contrato via RPC, não do localStorage). Token B permanece pendente. Não exige re-aprovação de Token A.

RN-34 — Propagação de estado para Tela 03. Após todos os tokens aprovados: o CTA "Continuar para revisão" avança para Tela 03, que carrega com o stepper na etapa "Confirmar" e sem o banner de "aprovação pendente" nos estados de erro.

4. Estados não-triviais

Nenhuma aprovação necessária (ambos aprovados): Tela 04 pulada. O usuário vai diretamente de Tela 02 para Tela 03. Stepper em Tela 03 exibe 2 etapas, não 3.

Um token aprovado, outro pendente: Token A: chip verde "Autorizado ✓". Token B: chip cinza "Pendente", botão "Autorizar [Token B]" ativo. CTA "Continuar para revisão" desabilitado.

Aguardando popup da carteira (0–3s): Spinner no botão do token + "Aguardando sua carteira...". Após 3s sem popup: "Não viu o popup? [Reabrir popup] | [Cancelar]."

Aprovação submetida, aguardando blockchain (> 3s): Status do token: chip "Autorizando..." com spinner. Estimativa: "Geralmente leva menos de 1 minuto."

Usuário cancelou a aprovação na carteira: Chip volta para "Pendente". Mensagem inline: "Você cancelou a autorização. [Tentar de novo]"

Falha de rede na transação de aprovação: Chip: "Erro — tente novamente". Mensagem: causa específica se disponível:

"Gas insuficiente. [Tentar de novo com gas mais alto]"
"Rede congestionada. [Tentar de novo]"
Genérico: "Não foi possível processar a autorização. [Tentar de novo] | [Ver detalhes]"

Gas muito alto detectado: Warning não-bloqueante: "O gas da rede está alto agora (aprox. R$ X,XX por autorização). Você pode aguardar ou usar 'Autorizar via assinatura' quando disponível."

Permit2 disponível (aprovação sem gas): Chip "Autorizar via assinatura (sem gas)" em destaque no topo da lista de chips. Badge verde "Recomendado — sem custo de gas". Botão do chip: "Autorizar sem gas".

Rede trocada durante o fluxo: Banner: "Você trocou para [Rede X]. As autorizações são específicas da rede [Rede Y] onde está sua posição. Troque de volta para continuar."

5. Microcopy crítico

Título e subtítulo:

Título: "Autorizar seus tokens"
Subtítulo: "Antes de criar sua posição, o protocolo precisa da sua autorização para movimentar os tokens escolhidos. Acontece uma vez por token."

Status do token:

"Pendente" (cinza)
"Autorizando..." (cinza com spinner)
"Autorizado ✓" (verde)
"Aprovação insuficiente — clique para complementar"
"Erro — tente novamente" (vermelho suave)

Chips de tipo de aprovação:

Exata: "Apenas para esta posição ([valor] [Token])"
Ilimitada: "Para todas as transações futuras (Ilimitado)" + badge ⚠
Permit2: "Autorizar via assinatura (sem gas)" + badge verde "Recomendado"

Tooltips de tipo:

Exata: "Você autoriza exatamente o valor desta posição. Para a próxima posição com este token, será necessária nova autorização."
Ilimitada: "Autoriza que o protocolo movimente qualquer quantidade futura de [Token] sem confirmação. Mais conveniente, mas concede mais acesso do que o necessário agora. Revogável em Gerenciar aprovações."
Permit2: "Assinatura off-chain — não é uma transação de rede, não cobra gas. Funciona como uma autorização segura e temporária."

Gas estimado: "Custo desta autorização: aprox. R$ X,XX" Tooltip: "Gas de rede. Você paga mesmo que não crie a posição depois. Autorização via assinatura, quando disponível, não tem este custo."

Modal de aprovação ilimitada:

Título: "Confirmar aprovação ilimitada"
Corpo: "Ao aprovar sem limite, você autoriza que o protocolo da Kotai movimente qualquer quantidade de [Token] da sua carteira em transações futuras, sem nova confirmação. Você pode revogar esta autorização a qualquer momento em Gerenciar aprovações."
CTA primário: "Usar valor exato desta posição" (azul — caminho mais seguro como ação padrão)
CTA secundário: "Confirmar aprovação ilimitada" (laranja — cor de alerta)

Estados de popup da carteira:

"Aguardando sua carteira... confirme o popup."
"Não viu o popup? [Reabrir popup] | [Cancelar]"
"Autorizando [Token] na rede..."
"A autorização está demorando. [Verificar no explorador ▸] | [Tentar de novo]"

CTAs principais:

Disabled (token pendente): "Autorizar tokens primeiro"
Enabled (todos aprovados): "Continuar para revisão"

6. Rastreabilidade obrigatória

🟢 Herdado

CTA com label que descreve o gap atual — "Autorizar tokens primeiro" vs "Continuar para revisão". [pancake-final § Pilar 6 — CTA dinâmico + Default contextual] + [uniswap-final § 🟢 Estados como instrução acionável]
Polling de confirmação com estado visível — chip "Autorizando..." com spinner em vez de loading mudo; timeout de 60s com rota de retorno. [pancake-final § 🟢 Cobertura proativa de estados não-triviais]
Rota de retorno explícita após handoff à carteira — "Não viu o popup? [Reabrir] | [Cancelar]" após 3s. [pancake-final § Fricção 8 — Abandono em handoff] + [uniswap-final § Fricção 9 — Handoff sem rastro]
Gas estimado com tooltip declarando custo condicional — "Você paga mesmo que não crie a posição depois." [uniswap-final § 🟢 Copy preventiva que declara o porquê]
Status de aprovação parcial persistido entre sessões — Token A marcado como aprovado ao retornar. [pancake-final § Pilar 6 — Default contextual em camadas]

🔴 Corrige

"Approve token: 115,792,089,237..." sem dizer "aprovação infinita" — a Kotai distingue aprovação exata de ilimitada com labels em PT-BR + modal Tier 2 para ilimitada. [uniswap-final § Fricção 1 — Léxico de protocolo — uint256 max como aprovação infinita]
Aprovação como estado de erro de recuperação em vez de passo previsto — a Kotai modela aprovação como passo proativo do fluxo, não como falha de transação. [uniswap-nova-posicao § Pontos isolados — aprovação aparece como erro em Tela 3] + [pancake-final § Fricção 12 — Estados intermediários sem padrão unificado]
Affordances nivelados para aprovação exata e ilimitada — aprovação ilimitada recebe modal Tier 2 e chip com ⚠; aprovação exata recebe botão direto. [uniswap-final § Fricção 7 — Affordances nivelados para ações de risco diferente] + [pancake-final § Fricção 3 — Listas sem hierarquia de consequência]
i18n parcial: "Approve" como label primário — toda a microcopy de aprovação em PT-BR; termos técnicos (EIP-2612, gas) apenas em tooltip/secondary. [pancake-final § Fricção 2 — i18n parcial] + [uniswap-final § Fricção 8 — i18n parcial]

🟡 Captura

Permit2 / aprovação sem gas como opção recomendada visível — nenhum concorrente apresenta aprovação sem gas como chip recomendado no fluxo de LP; é escondida em "Configurações avançadas" quando existe. Hipótese: mostrar "Autorizar via assinatura (sem gas)" como chip recomendado reduz abandono neste passo crítico; o usuário vê que pode economizar e associa a Kotai a "não cobra gas desnecessariamente". [uniswap-final § Pilar 6 — Smart wallet + abstração de fricção de protocolo] + [pancake-final § Pilar 7 — Mobile-first + eficiência de transação]
Aprovação residual como contexto persistente entre sessões — ao retornar após saída parcial, estado de aprovação de Token A é lido do contrato e exibido imediatamente. Hipótese: reduz abandono em re-entradas após perda de foco ou timeout de popup. [pancake-final § Fricção 8 — Abandono em handoff] — a Kotai vai além do diagnóstico: mantém contexto ativo.

⚪ Novo

Sequencialidade forçada de aprovações (Token A antes de Token B) como princípio de UI: nenhum consolidado especifica sequencialidade como princípio explícito de UX de aprovação — é interpretação da Kotai. Justificativa: dois popups simultâneos de aprovação confundem o usuário sobre qual transação está confirmando; confusão aumenta abandono e aumenta chance de assinar o popup errado. Evidência a coletar: taxa de aprovação bem-sucedida em fluxo sequencial vs paralelo (A/B test); % de usuários que precisam de retry em cada modelo.
Seletor de tipo de aprovação (exata vs ilimitada) visível no fluxo padrão: os consolidados identificam o problema (uint256 sem label) mas não especificam a UX de seleção na tela de aprovação. Justificativa: sem a escolha visível, o usuário assina o que a dApp decidiu — tipicamente infinito, sem consciência. Evidência a coletar: % de usuários que escolhem exata vs ilimitada quando ambas são visíveis; taxa de revogação posterior de aprovações ilimitadas como proxy de "arrependi-me".

7. Trade-offs e segunda ordem

Pulo automático quando todos aprovados: se o RPC falhar ao verificar o estado de aprovação, pode pular a tela erroneamente — resultando em falha de transação em Tela 03. Mitigação: Tela 03 re-verifica o estado de aprovação silenciosamente antes de habilitar o CTA final; se detectar falta de aprovação, redireciona para Tela 04 com estado preservado.

Sequencialidade de aprovações: pode ser percebida como lentidão por avançados que gerenciam nonces manualmente. Mitigação: nenhum opt-out — expor controle de nonce seria A2 (sobre-escopo). O custo de ~15s a mais para avançados é aceito para proteger iniciantes de popups simultâneos.

Stepper expandido para 3 passos: quando não há aprovações necessárias (estimativa: 60–70% dos retornos de usuários já aprovados), o stepper muda de 3 para 2 passos entre Tela 02 e Tela 03. Consistência: o stepper de Tela 01 e Tela 02 NÃO mostra o passo "Autorizar" — ele aparece apenas quando Tela 04 é exibida. Isso é intencional: não exibir passo que pode não existir evita ansiedade antecipada.

Modal de aprovação ilimitada (Tier 2): adiciona fricção que não existe em nenhum concorrente para aprovação ilimitada. Risco de A3 se o usuário legítimo que quer aprovação ilimitada (avançado que opera frequentemente com aquele token) for frustrado. Mitigação: o modal tem CTA de "Continuar com valor exato" como opção clara; avançados que leram o modal uma vez tendem a selecionar o chip certo na próxima vez (memória do seletor de tipo de aprovação pode ser persistida por token).

Estimativa de gas por aprovação: é uma estimativa pre-submission. Se o gas subir significativamente entre a estimativa e a submissão real, o usuário paga mais do que o exibido. Mitigação: badge "estimativa" no valor + tooltip "pode variar com congestionamento da rede". TTL do estimado: 30s (re-busca silenciosamente).

Criar Pool — Tela 05: Configuração de hook (Modo Programável — V4)

1. Função da tela

Permite que o usuário selecione e configure um hook (lógica customizada de terceiros) para sua posição V4, com curadoria visível, sinalização de risco proporcional à origem do hook, e barreira de consciência adequada antes de avançar. Foco: avançado (foco direto), intermediário que escolheu Modo Programável por curiosidade (precisa de orientação para não ativar hook por acidente ou por phishing).

Contexto narrativo: esta tela é a extensão explicitamente deferida da Tela 02, que descreve o Modo Programável como "compartilha o layout Concentrada com adição de uma seção de configuração de hook ao final (não detalhada nesta proposta — escopo de uma tela futura)." Aparece após a configuração de faixa e aporte (Tela 02 — Layout Programável) e antes da aprovação de tokens (Tela 04) / revisão (Tela 03).

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

2.1 Banner de contexto de modo avançado (persistente — não colapsável)

Background amarelo suave, ícone ⚠: "Você está configurando uma posição com lógica customizada (hook). Hooks são contratos de terceiros — a Kotai revisa alguns deles (badge ✓), mas isso não garante ausência de bugs ou perdas. Use apenas hooks de fontes em que você confia." Link: "O que é um hook? ▾" → expande painel educativo (ver microcopy seção 5).

2.2 Seletor de hook

Estado default: sem hook selecionado. Label da seção: "Adicionar lógica automática à sua posição (opcional)". Botão de expansão: "Escolher hook ▾".

Ao expandir, aparece painel de seleção com:

Campo de busca: "Buscar hook por nome, endereço ou protocolo"

Tabs de curadoria: "Verificados pela Kotai" (default, ativa) | "Populares" | "Todos". Transição para tabs não-verificadas exibe chip de aviso: "Saindo do espaço de hooks verificados."

Lista de hooks — cada card contém:

Nome do hook + ícone do protocolo (se reconhecido)
Descrição funcional em 1 linha em PT-BR (linguagem de benefício, não nome técnico)
Badge de verificação: "Verificado pela Kotai ✓" (verde) | "Auditado por [firma] ✓" (azul) | "Comunidade — não auditado" (cinza) | "Não verificado — use com cautela ⚠" (amarelo)
TVL ativo em pools usando este hook (se disponível): "R$ X,XX M em uso"
Maturidade: "Deployado há X meses"
Chip de tipo de automação: "Rebalanceamento automático" | "Coleta automática de taxas" | "Proteção de liquidez" | "Outro"

2.3 Card do hook selecionado (aparece após selecionar)

Nome + badge de verificação
Endereço do contrato truncado (ex: 0xABCD...1234) + link "Ver contrato no explorador ↗"
Seção "O que este hook faz:" — descrição funcional em 2–3 frases em PT-BR
Parâmetros configuráveis (específicos por hook — gerados dinamicamente pelo schema do hook):
- Cada parâmetro tem: label em PT-BR (benefício) + secondary label técnico + campo de input ou toggle + valor default sugerido + tooltip contextual
- Campos obrigatórios marcados com asterisco
- Campos opcionais com valor default exibido e possibilidade de reset
Estimativa de gas adicional: "Este hook adiciona aprox. R$ X,XX de gas por operação de gerenciamento da posição."
Botão "Remover hook — usar posição V4 padrão" (link discreto abaixo do card)

2.4 Banner de aviso de hook não-verificado (condicional — apenas para hooks sem badge "Verificado pela Kotai" ou "Auditado")

Background vermelho muito claro, texto vermelho escuro: "Este hook não foi auditado pela Kotai nem por uma firma de segurança reconhecida. Verifique o código-fonte antes de continuar." Link: "Ver contrato no explorador ↗" (obrigatório — link externo).

CTA de avanço permanece ativo, mas muda de label e cor (ver seção 2.5). Scroll sentinel: CTA só habilita após o usuário rolar até o final do banner.

2.5 CTA de avanço

Três estados conforme o hook selecionado:

Sem hook selecionado: "Continuar sem hook" (azul primário)
Hook verificado selecionado: "Usar [nome do hook]" (azul primário)
Hook não-verificado selecionado: "Usar hook não-verificado — estou ciente do risco" (laranja — cor de alerta, não azul primário: CTAs em contexto de risco não recebem cor primária)

Cosméticos (polish posterior)

2.6 Stepper — Segue o padrão de Tela 02; esta tela é parte do bloco "1 Configurar". 2.7 Breadcrumb — "Ganhar rendimento / Criar posição / Configurar hook"

3. Regras de negócio

RN-35 — Sem hook como default seguro. O estado default desta tela é "Nenhum hook selecionado". Posição V4 sem hook é tecnicamente válida (concentrated liquidity com fee tier dinâmica). O usuário que chegou ao Modo Programável por curiosidade pode avançar sem selecionar hook algum — o CTA "Continuar sem hook" está sempre disponível e em destaque.

RN-36 — Tab "Verificados pela Kotai" como default. A lista de hooks abre sempre na tab "Verificados pela Kotai". Para ver hooks da comunidade ou não-verificados, o usuário precisa clicar explicitamente em outra tab. O chip de aviso "Saindo do espaço de hooks verificados" aparece ao mudar de tab — informa, não bloqueia.

RN-37 — Busca por endereço de contrato. O campo de busca aceita endereço 0x... Se o endereço for válido e não estiver no catálogo: "Hook não encontrado no catálogo da Kotai. Você pode usar este endereço diretamente, mas ele não foi verificado." + banner vermelho de aviso imediatamente exibido. Parâmetros raw via ABI ficam disponíveis apenas quando o modo avançado global está ativado nas configurações.

RN-38 — Schema dinâmico de parâmetros. Cada hook expõe um schema de parâmetros via registro on-chain ou off-chain mantido pela Kotai. A UI renderiza os campos dinamicamente. Campos obrigatórios: validados antes de habilitar o CTA de avanço (parâmetros inválidos bloqueiam o CTA com label "Preencher os parâmetros obrigatórios"). Campos opcionais: têm default do hook e podem ser resetados.

RN-39 — Propagação para Tela 03. Hook selecionado + parâmetros configurados propagam para Tela 03, onde:

Banner "Este modo usa lógica personalizada (hook) de terceiros" é exibido com o nome e badge do hook
CTA da Tela 03 muda de "Criar minha posição" para "Criar minha posição com hook [nome]"
Se hook não-verificado: banner Tier 2 de aviso mais proeminente em Tela 03

RN-40 — Remoção de hook: retorno ao modo V4 sem hook. Ao clicar em "Remover hook — usar posição V4 padrão": modal de confirmação simples (Tier 3 — ação reversível): "Tem certeza? Você perderá as configurações deste hook." CTAs: "Remover hook" (cinza) | "Manter hook" (primário). Após confirmação: painel volta ao estado sem hook; CTA de avanço fica "Continuar sem hook" (azul).

RN-41 — Type-to-confirm não se aplica nesta tela. A seleção de hook não é ação Tier 1 — o usuário ainda precisa confirmar a transação em Tela 03, onde o aviso de hook de terceiros é exibido novamente. Dobrar a barreira aqui seria A3 (solução mais restritiva que o risco justifica). A barreira de consciência proporcional ocorre em Tela 03 (banner Tier 2 + CTA com label diferente), não aqui.

RN-42 — Schema indisponível: fallback para modo básico. Se o schema de parâmetros de um hook não puder ser carregado: "Não foi possível carregar as configurações deste hook. [Tentar de novo] | [Escolher outro hook]". CTA de avanço bloqueado até o schema ser carregado ou o usuário selecionar outro hook.

4. Estados não-triviais

Estado inicial — sem hook selecionado: Banner amarelo visível. Seletor de hook recolhido com botão "Escolher hook ▾". CTA: "Continuar sem hook" (azul primário).

Seletor de hook expandido: Lista de hooks na tab "Verificados pela Kotai" com campo de busca ativo. Skeletons enquanto o catálogo carrega.

Hook verificado selecionado: Card do hook visível com badge verde. Parâmetros configuráveis exibidos. Estimativa de gas. CTA: "Usar [nome do hook]" (azul primário).

Hook não-verificado selecionado: Banner vermelho claro com link obrigatório para explorador. Scroll sentinel ativo (CTA habilitado apenas após scroll até o banner). CTA: "Usar hook não-verificado — estou ciente do risco" (laranja).

Parâmetros obrigatórios inválidos: Campos com borda vermelha + mensagem inline. CTA: "Preencher os parâmetros obrigatórios" (disabled).

Loading do catálogo de hooks: Skeletons nos cards da lista. Timeout de 5s: "Não conseguimos carregar o catálogo. [Inserir endereço diretamente] | [Tentar de novo]"

Busca sem resultado:

Busca por nome: "Nenhum hook encontrado para '[query]' nesta tab. [Buscar em Todos ▸]"
Busca por endereço válido não encontrado: "Hook não encontrado no catálogo. Você pode usar este endereço, mas ele não foi verificado." + banner vermelho imediato.
Busca por endereço inválido: "Endereço inválido — verifique o formato (0x...)."

Schema de parâmetros indisponível: "Não foi possível carregar as configurações deste hook. [Tentar de novo] | [Escolher outro hook]" CTA bloqueado.

Rede errada para o hook selecionado: "Este hook não está deployado na rede atual ([Rede X]). Troque para [Rede Y] ou escolha outro hook."

5. Microcopy crítico

Banner de contexto: "Você está configurando uma posição com lógica customizada (hook). Hooks são contratos de terceiros — a Kotai revisa alguns deles (badge ✓), mas isso não garante ausência de bugs ou perdas. Use apenas hooks de fontes em que você confia." Link: "O que é um hook? ▾"

Painel educativo expandido (link "O que é um hook?"): "Um hook é um contrato externo que adiciona comportamento automático à sua posição de liquidez. Exemplos: rebalancear automaticamente quando o preço sai da faixa, coletar e reinvestir taxas sem ação manual, ou proteger a posição de tipos específicos de swap. Hooks são criados por terceiros — a Kotai verifica alguns deles, mas você é responsável por validar a origem de qualquer hook que usar."

Seletor de hook:

Label da seção: "Adicionar lógica automática à sua posição (opcional)"
Botão: "Escolher hook ▾"
Placeholder de busca: "Buscar por nome, endereço ou protocolo"
Tab default: "Verificados pela Kotai"
Aviso de troca de tab: "Saindo do espaço de hooks verificados."

Badges de verificação:

"Verificado pela Kotai ✓" (verde)
"Auditado por [firma] ✓" (azul)
"Comunidade — não auditado" (cinza)
"Não verificado — use com cautela ⚠" (amarelo)

Card de hook:

"TVL usando este hook: R$ X,XX M em uso"
"Deployado há X meses"
Chips de tipo: "Rebalanceamento automático" | "Coleta automática de taxas" | "Proteção de liquidez" | "Outro"
Gas adicional: "Este hook adiciona aprox. R$ X,XX de gas por operação de gerenciamento da posição."

Banner de aviso (hook não-verificado): "Este hook não foi auditado pela Kotai nem por uma firma de segurança reconhecida. Verifique o código-fonte antes de continuar." Link: "Ver contrato no explorador ↗"

Remoção de hook:

Link: "Remover hook — usar posição V4 padrão"
Modal: "Tem certeza? Você perderá as configurações deste hook."
CTA modal primário: "Manter hook"
CTA modal secundário: "Remover hook"

CTAs:

Sem hook: "Continuar sem hook" (azul primário)
Hook verificado: "Usar [nome do hook]" (azul primário)
Hook não-verificado: "Usar hook não-verificado — estou ciente do risco" (laranja)
Parâmetros inválidos: "Preencher os parâmetros obrigatórios" (disabled)

6. Rastreabilidade obrigatória

🟢 Herdado

Tab curada como default em listas com conteúdo de risco heterogêneo — padrão da análise de Leilões da Uniswap (badge "Verificado" + "Mostrar ocultos" como segunda classe). [uniswap-pools § 🟢 Transparência radical na cauda longa — badge verificado]
Fenestração da curadoria com chip de transição explícita ao mudar de tab — usuário sabe quando está saindo do espaço curado. [uniswap-final § Pilar 3 — Fenestração da curadoria silenciosa com critério clicável]
CTA de ação de risco em cor distinta da primária — hook não-verificado usa laranja; CTA de hook verificado usa azul primário. [pancake-final § Fricção 3 — "Turn On Expert Mode" verde — CTAs de risco em cor primária]
Estado default seguro como escolha ativa — "Nenhum hook" é o default; hook é opt-in explícito. [pancake-final § Pilar 5 — Curadoria opinionada por default + Modo avançado opt-in]
Scroll sentinel para conteúdo de risco obrigatório — CTA de hook não-verificado habilitado apenas após scroll até o banner (mesmo padrão da Tela 01 para pool novo). [uniswap-nova-posicao § Tela 01 — card de aviso de pool novo] + [pancake-final § Pilar 2 — Defesa em camadas proporcional ao risco]
Stepper e breadcrumb consistentes com o restante do fluxo — continuidade visual de Tela 02. [uniswap-nova-posicao § 🟢 Stepper pedagógico e contextual]

🔴 Corrige

Hook como caixa-preta técnica na UI da Uniswap — o campo atual é "'Adicionar um hook (Avançado) ⓘ'" com jargão técnico invasivo e link ambíguo entre campos pedagógicos. A Kotai tem seção dedicada com banner educativo, catálogo curado e labels de benefício. [uniswap-nova-posicao § 🔴 Ponto isolado — "Adicionar um hook (Avançado) ⓘ" — jargão técnico invasivo]
Ausência de curadoria de hooks com verificação visível — nenhum concorrente tem catálogo de hooks com badges de verificação, TVL em uso, ou maturidade de deploy. A Kotai aplica o mesmo sistema de risk signaling que usa em pools e tokens. [uniswap-final § Pilar 3 — Risk signaling sistêmico em listas] + [pancake-final § Pilar 3 — Risk signaling ausente em pontos de decisão]
Formulário que aceita lógica customizada sem pedagogia do risco — o Modo V4 atual não distingue "hook verificado" de "hook malicioso" na UI. [pancake-final § Fricção 7 — Aplicação inconsistente da defesa em camadas]
i18n: "hook" como jargão sem tradução — mantido em EN porque é termo de protocolo sem equivalente PT-BR estabelecido; toda a descrição funcional em PT-BR. [pancake-final § Fricção 2 — i18n parcial]

🟡 Captura

Catálogo curado de hooks com verificação como diferenciador — nenhum DEX tem catálogo de hooks verificados visível no fluxo de criação de posição. Hipótese: usuário V4 que confia no catálogo curado da Kotai tem menos chance de configurar hook malicioso; Kotai posiciona-se como "guardiã do ecossistema V4" com responsabilidade editorial declarada. [uniswap-final § Pilar 3 — Canonical mapping + risk signaling unificado]
Descrição funcional de hook em linguagem de benefício — "Rebalanceamento automático" em vez de nome técnico do contrato. Hipótese: usuário que vê "Rebalanceamento automático" consegue decidir se o hook é adequado ao seu perfil sem ler o código. [pancake-final § Pilar 1 — Naming system pelo benefício do usuário] + [pancake-adicionar-liquidez § 🟡 Oportunidade 2 — Filtros por consequência financeira]
Estimativa de gas adicional por hook visível antes da escolha — nenhum DEX mostra o overhead de gas de um hook no momento da seleção. Hipótese: usuário que vê "este hook adiciona R$ X,XX de gas por operação" pode comparar hooks não apenas por funcionalidade mas por custo operacional — decisão mais informada. [uniswap-final § Pilar 5 — Simulação ativa e assistência pré-commit]

⚪ Novo

Schema dinâmico de parâmetros por hook renderizado em campos de UI: nenhum consolidado especifica UI de parâmetros de hook — é interpretação da Kotai. Justificativa: é a única forma de escalar o catálogo sem hardcodar a interface de cada hook individualmente. Custo técnico: hooks precisam expor schema via registro on-chain ou off-chain maintido pela Kotai. Evidência a coletar: % de hooks com schema válido vs que precisam de UI hardcoded; taxa de configuração bem-sucedida (sem erro de parâmetro inválido) com e sem schema.
"Gas adicional estimado por hook" por operação de gerenciamento: estimar o overhead de gas específico de cada hook não tem origem direta nos consolidados. Justificativa: hooks podem adicionar custo significativo por interação com a posição (claim de taxas, rebalanceamento); o avançado que cria múltiplas posições com hooks precisa comparar esse custo antes de escolher. Evidência a coletar: acurácia do estimador vs gas real cobrado; % de usuários que mudam de hook após ver a estimativa de gas.

7. Trade-offs e segunda ordem

Catálogo curado de hooks: exige processo de curadoria contínuo (review de contratos, critérios de verificação, manutenção da lista). Risco legal: ao colocar badge "Verificado pela Kotai" em um hook com bug não detectado, a Kotai pode assumir responsabilidade implícita. Mitigação: disclaimer explícito e consistente "Verificado = revisado pela nossa equipe; não é garantia de ausência de bugs ou perdas". Custo de operação: médio-alto.

Schema dinâmico de parâmetros: custo de implementação alto para hooks com schemas complexos. Para MVP, alternativa pragmática: lista hardcoded dos 15–20 hooks mais populares com schemas específicos; "Inserir endereço personalizado" como escape hatch para avançados. A interface dinâmica completa pode ser iteração seguinte.

CTA laranja para hook não-verificado: pode parecer que a Kotai está desencorajando o V4 em geral. Risco de A3 (barreira excessiva para caso legítimo). Mitigação: o banner não é vermelho bloqueante mas laranja informativo; o CTA não é desabilitado mas muda de cor e label; avançados que sabem o que estão fazendo clicam sem fricção real além de 1 scroll.

Propagação de hook com parâmetros para Tela 03: o hook e seus parâmetros precisam ser serializados na URL parametrizada para preservação de estado. Hooks com parâmetros complexos (arrays, structs) podem gerar URLs longas. Mitigação: serializar parâmetros em hash de estado no localStorage com UUID referenciado na URL.

Scroll sentinel para hook não-verificado: mesmo padrão da Tela 01 (pool novo). Risco de inconsistência se a Tela 01 remover o scroll sentinel em iteração futura. Mitigação: o scroll sentinel é um padrão nomeado no design system da Kotai, não uma solução pontual — qualquer alteração deve ser aplicada globalmente.

Criar Pool — Tela 06: Pool novo — definição do preço inicial

1. Função da tela

Guiar o usuário que está criando o primeiro pool de um par pela definição do preço inicial — o único passo do fluxo com risco de perda financeira direta e imediata no momento da criação, derivada de arbitragem automática nos primeiros blocos. Foco: intermediário (principal — criar pool novo é um ato incomum que pressupõe alguma familiaridade), iniciante que chegou aqui por acidente (precisa de proteção máxima e pedagogia clara antes de avançar).

Contexto narrativo: esta tela foi mencionada em todas as três telas anteriores como um sub-fluxo especial, mas nunca recebeu design dedicado. A Tela 01 exibe um card expandido "Você será o primeiro provedor — você define o preço inicial". A Tela 02 inclui um campo inline de preço inicial no card de saúde do pool. A Tela 03 tem um checkbox de consciência e banner de pool novo. A Tela 06 é o design completo desse caso: uma tela dedicada com referência de oracle, gauge de desvio e estimativa de perda — porque a semântica e o risco de criar um pool novo são radicalmente diferentes de aportar em pool existente, e não cabem em estado inline de outra tela sem perder a densidade de proteção necessária.

Posicionamento no fluxo: aparece após a Tela 02 (configuração) e antes da Tela 04 (aprovação de tokens) / Tela 03 (revisão). É pulada completamente quando o pool já existe.

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

2.1 Banner de contexto de pool novo (sempre expandido, não colapsável nesta tela)

Background azul suave (informa, não alarma — o usuário não cometeu um erro, está tomando uma decisão): "Você será o primeiro a fornecer liquidez para [Token A]/[Token B]. O preço que você definir se torna o preço de câmbio inicial deste pool. Se estiver muito diferente do mercado, bots de arbitragem corrigem automaticamente nos primeiros segundos — e você perde parte do aporte." Link: "Como isso funciona? ▾" → painel educativo expandível (ver seção 5).

2.2 Painel de referência de preço de mercado

Título: "Preço de mercado atual"
Linha principal: "1 [Token A] = [valor oracle] [Token B]"
Linha invertida: "1 [Token B] = [valor calculado] [Token A]"
Fonte: "Fonte: [nome do oracle] • Atualizado às [HH:MM]" + botão "Atualizar ↻"
Se oracle indisponível: banner amarelo "Preço de mercado indisponível para este par." + links para fontes externas (CoinGecko, CoinMarketCap + par em outro DEX se detectável).

2.3 Campo de preço inicial (componente principal da tela)

Label: "Preço inicial que você está definindo"
Input: "1 [Token A] = [input numérico] [Token B]" — separador decimal PT-BR (vírgula)
Pré-preenchido com o valor do oracle quando disponível (default seguro)
Botão ao lado do input: "Usar preço de mercado" — recalcula com oracle e limpa qualquer edição manual
Botão de inversão "↕ Mostrar invertido" — alterna exibição para "1 [Token B] = [valor calculado] [Token A]", útil para pares com ratio < 0,01 (auto-flip por magnitude)
Linha abaixo do input: "Equivalente: R$ [valor em BRL] por [Token A]" — âncora em moeda local

2.4 Indicador de desvio do preço (aparece após o usuário digitar ou editar o preço)

Gauge horizontal com três zonas coloridas:

Zona verde (central, ±1%): "✓ Alinhado com o mercado"
Zona amarela (1–5%): "⚠ Pequeno desvio"
Zona vermelha (> 5%): "⛔ Desvio alto"

Label dinâmico abaixo do gauge:

< 1%: "✓ Alinhado com o mercado (desvio de X%)"
1–5%: "⚠ Desvio de X% — pode haver arbitragem nos primeiros blocos"
5%: "⛔ Desvio de X% — estimativa de perda: até Y% do aporte na criação"

O valor Y da estimativa de perda é calculado com base na fórmula de AMM (x*y=k para V2 / CLMM para V3-V4) para o desvio informado. Tooltip do indicador: "Estimativa baseada na mecânica padrão de AMM. Resultado real depende do capital arbitrado nos primeiros blocos e das condições de liquidez."

Botão "Ajustar para o preço de mercado" aparece quando desvio > 5% — link de ação imediata acima do gauge.

2.5 Simulador de composição do aporte (aparece após o campo de preço ser preenchido)

"Com o preço que você definiu, sua posição ficaria assim:"

Token A: [valor que o usuário configurou na Tela 02] [Token A] — R$ [equivalente BRL]
Token B: [valor que o usuário configurou na Tela 02] [Token B] — R$ [equivalente BRL]
Total: "Total na posição: R$ [soma]"

Nota: "Os valores de aporte estão fixos. O preço que você define aqui determina a taxa de câmbio inicial — não os valores depositados."

2.6 Confirmação de consciência (Tier 2)

Checkbox não marcado por default. Label: "Entendo que o preço que defini ([valor]) será o preço inicial deste pool. Se estiver muito diferente do mercado, parte do meu aporte pode ser tomada por arbitragem nos primeiros blocos." CTA de avanço fica disabled até o checkbox ser marcado.

2.7 CTA de avanço

Quatro estados sequenciais:

Sem preço definido: "Definir o preço inicial primeiro" (disabled)
Preço definido, checkbox não marcado: "Confirmar entendimento para continuar" (disabled)
Preço definido + checkbox marcado + desvio ≤ 30%: "Criar pool com este preço" (azul primário)
Preço definido + checkbox marcado + desvio > 30%: "Criar pool com desvio de [X%] — estou ciente" (laranja — cor de alerta, não azul primário)

Cosméticos (polish posterior)

2.8 Stepper — Segue o padrão dos demais; esta tela é etapa intermediária antes de "Confirmar". 2.9 Breadcrumb — "Ganhar rendimento / Criar posição / Definir preço inicial"

3. Regras de negócio

RN-43 — Pré-preenchimento com oracle como default seguro. Quando oracle disponível: campo de preço pré-preenchido com o preço de mercado atual ao entrar na tela. O indicador de desvio começa em 0% (verde). O usuário pode ajustar, mas o default protege contra perda por arbitragem no caso mais comum (pool novo para par com liquidez em outra plataforma).

RN-44 — Tela 06 aparece SOMENTE para pool novo. Pool novo = par (Token A, Token B, fee tier) sem contrato deployado na rede ativa. Se existir pool — mesmo com TVL zero, mesmo inativo — esta tela é pulada e o fluxo segue para Tela 04 (aprovações) / Tela 03 (revisão). A verificação é feita na Tela 01 (card de saúde do pool); a Tela 06 recebe o estado como parâmetro de URL.

RN-45 — Bloqueio de desvio extremo (> 50%) com modal obrigatório. Ao clicar no CTA com desvio > 50%, antes de avançar: modal de consciência (não type-to-confirm — é Tier 2): "Você está definindo um preço [X]% [acima/abaixo] do preço de mercado atual ([valor oracle]). Pools criados com preço muito desviado são corrigidos por arbitragem no primeiro bloco. Se for intencional, clique em 'Criar mesmo assim'. Se não for, revise o preço." CTA primário do modal: "Revisar o preço" (azul — incentiva revisão). CTA secundário: "Criar mesmo assim — sei o que estou fazendo" (cinza). O CTA secundário avança para o próximo passo. (Copy do modal alinhado ao microcopy da seção 5.)

RN-46 — Oracle indisponível: modo de preço manual sem referência. Quando oracle indisponível: campo de preço fica em branco sem pré-preenchimento. O indicador de desvio fica oculto (sem referência para comparar). Banner amarelo: "Não temos o preço de mercado para este par. Verifique o preço em outras plataformas antes de definir o preço inicial." Links externos para fontes sugeridas. O usuário pode digitar o preço manualmente e avançar — a tela não bloqueia, apenas informa.

RN-47 — Campos de aporte independentes para pool novo. Como definido na Tela 02 (RN-11): os campos de aporte Token A e Token B são independentes em pool novo. O preço inicial define apenas a razão de câmbio inicial, não os valores depositados. Se o usuário modificar o preço inicial após ter preenchido os aportes na Tela 02: aviso inline "O preço inicial foi alterado. Revise os aportes se necessário." — não recalcula automaticamente (preservar o que o usuário digitou é mais seguro que recalcular silenciosamente).

RN-48 — Propagação para Tela 03. Preço inicial definido + checkbox marcado propagam para Tela 03. A Tela 03 exibe:

Banner azul de pool novo com o valor do preço: "O preço inicial que você definiu ([valor]) ficará registrado na blockchain."
O checkbox de Tela 03 (Tier 2) está pré-marcado se o checkbox desta tela foi marcado. Tela 03 exige marcação independente — são barreiras distintas (definição de preço aqui; confirmação final lá).

RN-49 — Race condition: pool criado por terceiro durante o fluxo. Se um bot criar o pool (front-run) entre a Tela 01 e a chegada à Tela 06: ao entrar na tela, o sistema re-verifica o estado do pool. Se o pool agora existe: exibe mensagem "Alguém acabou de criar este pool. Suas configurações foram preservadas — você pode continuar aportando ao pool recém-criado." e redireciona para Tela 02 com configuração de "pool existente" (aportes já digitados mantidos via URL).

RN-50 — Auto-flip de preço por magnitude. Quando ratio Token A/Token B < 0,001 na representação direta (ex: BTCB/USDT): o botão "↕ Mostrar invertido" fica ativo por default e o campo exibe "1 [Token B] = [valor] [Token A]" automaticamente. Badge discreto "(invertido)" abaixo do campo. Mesmo padrão da Tela 02 (RN-17).

4. Estados não-triviais

Pool novo com oracle disponível (caso padrão): Campo pré-preenchido com valor do oracle. Indicador de desvio: "✓ Alinhado com o mercado (0%)". Checkbox desmarcado. CTA: "Confirmar entendimento para continuar" (disabled até marcar).

Pool novo sem oracle: Campo em branco. Banner amarelo "Preço de mercado indisponível". Indicador de desvio oculto. CTA: "Definir o preço inicial primeiro" (disabled) até o usuário digitar algo.

Desvio pequeno (1–5%): Gauge amarelo. Label: "⚠ Desvio de X%". CTA permanece azul padrão após checkbox marcado.

Desvio alto (> 5% e ≤ 30%): Gauge vermelho. Label: "⛔ Desvio de X% — estimativa de perda: até Y%". Botão "Ajustar para o preço de mercado" visível. CTA azul após checkbox.

Desvio muito alto (> 30%): Gauge vermelho. CTA laranja: "Criar pool com desvio de [X%] — estou ciente". Botão "Ajustar para o preço de mercado" proeminente.

Desvio extremo (> 50%): Modal obrigatório ao clicar no CTA — antes de avançar. CTA primário do modal: "Revisar o preço". CTA secundário: "Criar mesmo assim".

Oracle desatualizado (atualização falha): Badge inline "⚠ Preço pode estar desatualizado" ao lado do painel de referência. Botão "Atualizar ↻" com spinner. Após 3 tentativas: "Não conseguimos verificar o preço de mercado. Use fontes externas antes de continuar." + links para CoinGecko, CoinMarketCap.

Checkbox marcado + preço alinhado: CTA azul ativo: "Criar pool com este preço".

Pool criado por terceiro durante a sessão (race condition): Banner: "Este pool foi criado por outra pessoa enquanto você configurava. Suas configurações foram preservadas. Você pode continuar aportando ao pool agora." Botão: "Continuar para configuração de aporte". Tela redireciona para Tela 02 em modo "pool existente".

5. Microcopy crítico

Banner de contexto: "Você será o primeiro a fornecer liquidez para [Token A]/[Token B]. O preço que você definir se torna o preço de câmbio inicial deste pool. Se estiver muito diferente do mercado, bots de arbitragem corrigem automaticamente nos primeiros segundos — e você perde parte do aporte." Link: "Como isso funciona? ▾"

Painel educativo expandido: "Imagine que você está abrindo uma loja de câmbio e colocando o primeiro preço na vitrine. Se você cobrar R$ 5,00 por 1 dólar quando o mercado pratica R$ 5,50, os primeiros clientes compram todos os seus dólares a R$ 5,00 imediatamente — e você perde a diferença. Em DeFi isso acontece em segundos, automaticamente, via programas chamados bots de arbitragem. Eles monitoram novos pools e corrigem qualquer preço desviado antes que você possa reagir."

Painel de referência:

Título: "Preço de mercado atual"
"1 [Token A] = [valor] [Token B]"
"Atualizado às [HH:MM]"
Botão: "Atualizar ↻"
Sem oracle: "Preço de mercado indisponível para este par. Verifique em: [CoinGecko ↗] [CoinMarketCap ↗]"

Campo de preço:

Label: "Preço inicial que você está definindo"
Placeholder: "Ex: [valor do oracle]"
Botão reset: "Usar preço de mercado"
Label secundário: "Equivalente: R$ [valor] por [Token A]"
Botão inversão: "↕ Mostrar como 1 [Token B] = X [Token A]"

Indicador de desvio:

0–1%: "✓ Alinhado com o mercado (desvio de X%)"
1–5%: "⚠ Desvio de X% — pode haver arbitragem nos primeiros blocos"
5%: "⛔ Desvio de X% — estimativa de perda: até Y% do aporte na criação"
Tooltip: "Estimativa baseada na mecânica padrão de AMM. Resultado real depende do capital arbitrado e das condições de liquidez."
Botão contextual: "Ajustar para o preço de mercado"

Nota abaixo do simulador: "Os valores de aporte estão fixos (configurados na etapa anterior). O preço que você define aqui determina a taxa de câmbio inicial — não os valores depositados."

Checkbox de consciência: "Entendo que o preço que defini ([valor]) será o preço inicial deste pool. Se estiver muito diferente do mercado, parte do meu aporte pode ser tomada por arbitragem nos primeiros blocos."

CTAs:

Sem preço: "Definir o preço inicial primeiro" (disabled)
Preço definido, sem checkbox: "Confirmar entendimento para continuar" (disabled)
Preço + checkbox, desvio normal: "Criar pool com este preço" (azul)
Preço + checkbox, desvio > 30%: "Criar pool com desvio de [X%] — estou ciente" (laranja)

Modal de desvio extremo (> 50%):

Título: "Desvio muito alto"
Corpo: "Você está definindo um preço [X]% [acima/abaixo] do preço de mercado atual ([valor oracle]). Pools criados com preço muito desviado são corrigidos por arbitragem no primeiro bloco. Se for intencional, clique em 'Criar mesmo assim'. Se não for, revise o preço."
CTA primário: "Revisar o preço" (azul)
CTA secundário: "Criar mesmo assim — sei o que estou fazendo" (cinza)

6. Rastreabilidade obrigatória

🟢 Herdado

Pré-preenchimento com o preço de oracle como default seguro — default contextual que evita o erro mais comum (preço muito desviado) sem bloquear o avançado que quer um preço diferente. [uniswap-final § 🟢 Defaults agregados que respeitam o modelo mental do usuário] + [pancake-final § 🟢 Defaults pró-iniciante sem pedir permissão]
Copy preventiva que declara o que vai acontecer antes de acontecer — "Se estiver muito diferente do mercado, bots de arbitragem corrigem automaticamente nos primeiros segundos — e você perde parte do aporte." [uniswap-final § 🟢 Copy preventiva que declara o porquê / o que NÃO acontece]
Equivalente em BRL ao lado do preço definido — âncora em moeda local do target. [uniswap-final § 🟢 Múltiplas representações do mesmo dado + bidirecionalidade]
Auto-flip de preço por magnitude — botão "↕ Mostrar invertido" ativo por default quando ratio < 0,001. [pancake-final § Pilar 7 — Mobile-first + BR/LatAm — auto-flip de preço por magnitude]
Checkbox de consciência Tier 2 — padrão de barreira proporcional ao risco, consistente com Tela 03 (pool novo também tem checkbox na revisão). [pancake-final § Pilar 2 — Defesa em camadas universal + hierarquia de consequência]
Banner de pool novo sempre visível e não colapsável — o risco desta tela justifica o espaço permanente; colapsável seria A3 (proteção abaixo do risco). [uniswap-nova-posicao § Observações adicionais — Caso "pool ainda não existe" — risco de arbitragem imediata]

🔴 Corrige

Ausência de UX dedicada para o caso "pool ainda não existe" — todos os DEXes tratam pool novo como estado inline da tela de configuração, sem sub-fluxo dedicado. A Kotai tem tela específica porque a semântica e o risco são radicalmente diferentes. [uniswap-nova-posicao § Observações adicionais — "pool ainda não existe" — semântica e risco radicalmente diferentes do aporte em pool existente]
Campo de preço inicial sem referência de mercado — Uniswap e Pancake mostram o campo sem âncora de preço externo; usuário digita no escuro. A Kotai corrige com painel de oracle sempre visível e pré-preenchimento automático. [uniswap-nova-posicao § 🔴 Estrutural — Ausência de estado do pool destino na janela de decisão]
Formulário que aceita criação de pool novo sem validar o desvio de preço — nenhum concorrente compara o preço definido pelo usuário com o oracle e exibe o desvio em tempo real. [uniswap-final § Pilar 5 — Pré-visualização rica antes de input]
i18n: "price" como campo de preço sem localização — toda a microcopy de preço em PT-BR; separador decimal via vírgula; BRL ao lado de todo valor numérico. [pancake-final § Fricção 2 — i18n parcial] + [uniswap-final § Fricção 8]

🟡 Captura

Indicador de desvio com estimativa de perda por arbitragem — nenhum DEX mostra "com X% de desvio, você pode perder até Y% do aporte". Hipótese: usuário que vê "desvio de 8% → perda estimada de 4%" ajusta o preço antes de criar o pool com mais frequência do que usuário que vê apenas uma cor de aviso; reduz pools criados com preço desviado e melhora a confiança no produto. [uniswap-final § Pilar 5 — Simulação ativa e assistência pré-commit — "Mensagem de erro com saída" e cálculo de impacto]
Analogia pedagógica da "loja de câmbio" no ponto de maior incompreensão — educação contextual em PT-BR inline, sem link para docs externos. Hipótese: usuário iniciante que entende a analogia da vitrine de câmbio não sai com preço desviado — retém capital que seria arbitrado. [pancake-final § Pilar 4 — Educação contextual sistêmica + transparência financeira ativa] + [pancake-final § 🟢 Pedagogia embutida no ponto de decisão]
CTA adaptado por nível de desvio (azul → laranja → modal) — sinalização de risco proporcional sem bloqueio desnecessário. Hipótese: CTA laranja para desvio > 30% faz o usuário pausar e ler o desvio sem impedir a ação legítima. [pancake-final § Pilar 2 — Defesa em camadas proporcional ao risco]
Botão de reset "Usar preço de mercado" — ação de recuperação imediata para usuário que errou na digitação. Hipótese: presença do botão de reset visível reduz a taxa de saída da tela por desvio acidental (usuário que vê o desvio e quer corrigir tem um caminho de 1 toque). [uniswap-final § 🟢 Estados como instrução acionável]

⚪ Novo

Gauge visual de desvio com estimativa de perda percentual: o gauge com estimativa "Y% de perda estimada" não tem origem direta nos consolidados — é interpretação da Kotai aplicando a lógica de simulação pré-commit a este caso específico. Justificativa: usuários que veem um número concreto (não apenas uma cor) ajustam o preço com mais frequência; o número âncora ("perda de 4%") cria urgência calibrada sem paternalismo. Custo: modelo matemático de AMM para cálculo de impacto de arbitragem, específico por tipo de pool (x*y=k para V2, CLMM para V3-V4). Evidência a coletar: % de usuários com desvio > 5% que ajustam o preço após ver a estimativa vs apenas a cor de alerta; taxa de pools criados com desvio < 1% antes e depois da estimativa visível.
Analogia pedagógica específica ("loja de câmbio / vitrine de preço"): o exemplo concreto em PT-BR não tem origem direta nos consolidados. Os relatórios identificam a necessidade de pedagogia contextual no ponto de decisão mas não especificam a analogia. Justificativa: a analogia da loja de câmbio é familiar para o target BR/LatAm vindo de CEX e de câmbio físico — é um frame de referência que já existe no universo financeiro do iniciante BR, sem precisar de abstração adicional. Evidência a coletar: teste de usabilidade — usuário que lê a analogia consegue responder corretamente "o que acontece se eu definir o preço muito acima do mercado?" vs usuário que lê apenas o banner técnico.

7. Trade-offs e segunda ordem

Oracle como fonte de referência de preço: depende de oracle externo confiável (Chainlink, Pyth, ou TWAP de outro pool). Se o oracle estiver desatualizado ou indisponível, o campo fica em branco e o indicador de desvio fica inacessível. Mitigação: timestamp "Atualizado às HH:MM" sempre visível; botão de atualização manual; links para fontes externas quando oracle falha. Custo de engenharia: integração com oracle — médio.

Estimativa de perda por arbitragem: o cálculo depende de modelo matemático simplificado (x*y=k ou CLMM). Para pares com lógica de curva customizada (hooks V4, StableSwap), o modelo pode subestimar ou superestimar a perda. Mitigação: disclaimer sempre visível "estimativa baseada na mecânica padrão de AMM; varia com hooks ou lógica customizada". Risco de ganhar desconfiança se a estimativa for consistentemente imprecisa — aceitável se o disclaimer for honesto.

Quatro estados do CTA por desvio: o CTA muda de label e cor em tempo real conforme o usuário digita o preço. Cada estado precisa de lógica de debounce (evitar re-render a cada caractere). O delay de debounce deve ser < 300ms para parecer responsivo em mobile — custo de UX se muito lento.

Race condition: pool criado durante o fluxo: baixa probabilidade para pares obscuros; mais provável para pares de alta demanda. A detecção exige uma verificação on-chain ao iniciar a transação (já feita em Tela 03). A mensagem de race condition é informativa, não um erro — o usuário pode continuar com as configurações já definidas.

Redundância com campo inline da Tela 02: a Tela 02 já mostra um campo de preço inicial no card de saúde do pool para pools novos. A Tela 06 expande esse campo com oracle, gauge e estimativa. Há sobreposição: o usuário digita o preço duas vezes (uma vez em Tela 02, uma vez em Tela 06). Mitigação: o valor digitado na Tela 02 é propagado como pré-preenchimento para o campo da Tela 06; o usuário pode confirmar ou ajustar. A Tela 02 remove seu campo inline de preço inicial em favor de um banner "Você definirá o preço inicial na próxima etapa ▸" — simplifica a Tela 02 e centraliza a configuração de preço na Tela 06.

"Don't show this again" não é aplicável: a confirmação de consciência desta tela não pode ser ignorada em sessões futuras — criar um pool novo é sempre um ato novo com risco real. Alinhado com o princípio de que "'Don't show this again' é proibido em warnings Tier 1" do Pilar 2 (pancake-final). Neste caso, o risco não é Tier 1 puro (o capital não é perdido totalmente — pode ser parcialmente arbitrado), mas a frequência baixa da ação e o risco real de perda parcial justificam manter a barreira de consciência sempre ativa.

Tela 05 — Suas Posições: Estado sem carteira conectada

1. Função da tela

É a porta de entrada do fluxo para o usuário que ainda não conectou — ou não tem — uma carteira. Resolve o problema de "não sei por onde começar a usar DeFi" para o iniciante absoluto, e o problema de "quero conectar minha wallet" para o intermediário. Foco duplo: iniciante BR sem wallet prévia (público prioritário) + intermediário que quer acessar suas posições existentes.

2. Componentes / elementos

Estruturais

2.1 Header global

Tabs: Negociar · Explorar · Ganhar rendimento ✓ · Portfólio
- "Ganhar rendimento" substitui "Pool" como label de navegação (Pilar 1 — verbo de intenção)
- "Suas posições" é a sub-seção ativa dentro de "Ganhar rendimento"
CTA no canto superior direito: Entrar (texto neutro; abre o painel de entrada — ver §2.2)

2.2 Painel central de entrada (componente principal da tela) Estrutura em duas faixas verticais:

Faixa A — Título e contexto

Título: Suas posições
Subtítulo: "Acompanhe e gerencie suas posições de liquidez."

Faixa B — Dois caminhos de entrada (estrutural; define o paradigma) Apresentados como dois blocos distintos com divisória visual entre eles — não dois botões planos paralelos.

Bloco 1 — "Primeira vez aqui?" (expandido, maior hierarquia)

Label: Criar conta gratuita
Subtexto: "Entre com e-mail ou Google. Sua carteira é criada automaticamente — seus fundos, seu controle."
CTA primário: Criar conta com e-mail (botão cheio, cor de ação)
CTA alternativo: Continuar com Google (botão com ícone Google, outline)
Microcopy de custódia: "Kotai não tem acesso aos seus fundos. Você é o único dono."

Bloco 2 — "Já tem carteira?"

Label: Conectar carteira existente
Subtexto: "MetaMask, Coinbase Wallet, WalletConnect e outras."
CTA secundário: Conectar carteira (botão outline, hierarquia visual menor que o Bloco 1)

Link de escape para exploradores (abaixo dos dois blocos)

"Ainda explorando? Veja pools sem conectar →"
Navega para a listagem pública de pools sem exigir identidade

2.3 Cards educacionais (dois, abaixo do painel de entrada) Visíveis enquanto usuário lê e decide — empty state como espaço editorial (não placeholder mudo).

Card A — Iniciante (hierarquia visual maior)

Ícone: livro ou lampada simples
Título: Primeira vez provendo liquidez?
Corpo: "Aprenda como ganhar com as taxas de trading em 3 minutos."
CTA: Como funciona → (link, abre guia ou modal educacional)

Card B — Intermediário (hierarquia visual menor)

Ícone: gráfico de barras
Título: Fornecer liquidez em diferentes redes
Corpo: "Compare estratégias de range entre Base, Arbitrum e Ethereum."
CTA: Explorar → (link)

2.4 Sidebar de discovery (coluna direita — desktop)

Seção: Maiores pools por rendimento
Lista de 5–6 pools com: par de tokens · APR de fees (30d) · Rede
APR exibido como: APR de fees (30d): 4,89% (não APR isolado)
Badge de caveat ao lado de APR > 50%: "Alto rendimento — verifique risco de IL" (chip pequeno, discreto)
Link: Explorar todos os pools →
Seção secundária: Saiba mais sobre liquidez (links educacionais — Card A e Card B replicados como links)

3. Regras de negócio

Hierarquia dos caminhos de entrada

Bloco 1 ("Criar conta") tem maior peso visual por ser o caminho que serve o maior pool de usuários potenciais (iniciante sem wallet). Bloco 2 existe para não perder o intermediário. A hierarquia não é empurrar criação de conta — é respeitar o perfil majoritário do estado desta tela (sem wallet conectada = possivelmente sem wallet alguma).

Embedded wallet (Bloco 1)

Criar conta com e-mail → flow de onboarding de smart wallet (Privy / Dynamic / similar): e-mail → OTP → passkey → wallet criada; chave privada nunca passa pelo servidor Kotai.
Continuar com Google → OAuth → mesmo flow de smart wallet com social recovery.
Após criação: usuário cai na Tela 06 (hub conectado, zero posições) com banner de boas-vindas e sugestão de primeira posição.

Conectar carteira existente (Bloco 2)

Abre painel de seleção de wallets (componente padrão Kotai — ver fluxo Conectar Carteira).
Após conexão bem-sucedida: navega para Tela 06.

Link de escape

Veja pools sem conectar → navega para o hub de discovery de pools (Explorar → seção Pools) sem exigir identidade. Sidebar de "Maiores pools" na própria tela já serve parte desse papel.

Cards educacionais

Sempre visíveis nesta tela, independente de scrolling.
Card A e Card B são estáticos (não personalizados — identidade ainda não conhecida).
No mobile, os cards ficam abaixo do painel de entrada em layout de coluna única (sem sidebar).

Sidebar

Visível apenas no desktop (viewport ≥ 768px); no mobile, condensada como seção de scroll abaixo dos cards educacionais.
Carrega dados de pools independentemente de qualquer identidade (consulta pública de on-chain / subgraph).

4. Estados não-triviais

Vazio — sem dados de pools para a sidebar

Sidebar exibe skeleton de lista enquanto carrega; após 5s sem resposta, mostra: "Não foi possível carregar pools. [Tentar novamente]"
Painel central de entrada é independente de dados externos — nunca em estado de erro por falha da sidebar.

Loading — carregando sidebar

Skeleton nas linhas de pools da sidebar; painel central de entrada renderiza imediatamente (não depende de dados).

Erro — falha no flow de criação de conta (Bloco 1)

Se OTP de e-mail falhar: "Não conseguimos enviar o código. Verifique o e-mail e tente novamente." + botão Reenviar código.
Se OAuth Google falhar: "Autenticação com Google falhou. Tente com e-mail ou conecte uma carteira existente."
Se criação de smart wallet falhar: "Ocorreu um erro ao criar sua conta. Seus fundos não foram afetados. [Tentar novamente]"

Erro — falha na conexão de carteira (Bloco 2)

Tratado pelo componente de seleção de wallets (fluxo Conectar Carteira) — não duplicar lógica aqui.

Sucesso — conta criada (Bloco 1)

Banner de boas-vindas ao navegar para Tela 06: "Conta criada! Sua carteira está pronta. Veja pools recomendadas para sua primeira posição."

Sucesso — carteira conectada (Bloco 2)

Navegação direta para Tela 06 sem banner adicional (usuário já sabe o que fez).

Estado parcial — conexão EVM ok, Solana falhou

Não aplicável nesta tela (conexão ainda não aconteceu). Tratado na Tela 06 após conexão.

Rede errada após conexão

Não aplicável nesta tela — detectado após conexão (Tela 06).

5. Microcopy crítico

Título da tela

Suas posições

Subtítulo

"Acompanhe e gerencie suas posições de liquidez."

Bloco 1 — Criar conta

Label do bloco: Primeira vez aqui?
CTA primário: Criar conta com e-mail
CTA alternativo: Continuar com Google
Subtexto: "Sua carteira é criada automaticamente — seus fundos, seu controle."
Microcopy de custódia: "Kotai não tem acesso aos seus fundos. Você é o único dono."

Bloco 2 — Conectar existente

Label do bloco: Já tem carteira?
CTA: Conectar carteira
Subtexto: "MetaMask, Coinbase Wallet, WalletConnect e outras."

Link de escape

"Ainda explorando? Veja pools sem conectar →"

Card A — Iniciante

Título: Primeira vez provendo liquidez?
Corpo: "Aprenda como ganhar com as taxas de trading em 3 minutos."
CTA: Como funciona →

Card B — Intermediário

Título: Fornecer liquidez em diferentes redes
Corpo: "Compare estratégias de range entre Base, Arbitrum e Ethereum."
CTA: Explorar →

APR na sidebar

Label: APR de fees (30d)
Badge de alto rendimento: "Alto rendimento — verifique risco de IL"

Erros de criação de conta

OTP falhou: "Não conseguimos enviar o código. Verifique o e-mail e tente novamente." + Reenviar código
Google falhou: "Autenticação com Google falhou. Tente com e-mail ou conecte uma carteira existente."
Smart wallet falhou: "Ocorreu um erro ao criar sua conta. Seus fundos não foram afetados." + Tentar novamente

6. Rastreabilidade obrigatória

🟢 Herdado

Empty state como espaço editorial — cards educacionais em vez de placeholder mudo. [uniswap suas-posicoes-05 § Insight 1]
Sidebar de discovery independente de identidade — "Maiores pools" funciona com ou sem wallet; discovery é pública. [uniswap suas-posicoes-05 § Insight 2] [uniswap consolidado suas-posicoes § Separação visual entre gestão pessoal e discovery pública]
Caminho de exploração disponível sem conectar — Veja pools sem conectar → permite que usuário exploratório não se bloqueie. [uniswap suas-posicoes-05 § Insight 3]
Separação entre UI de discovery (pública) e UI de gestão (privada) — sidebar de pools funciona independente; painel central de entrada exige identidade. [uniswap consolidado suas-posicoes § Separação visual]

🔴 Corrige

Dois caminhos distintos com hierarquia clara (em vez de dois CTAs paralelos ambíguos) — Uniswap apresenta Nova posição (outline) + Conectar carteira (branco) com peso visual similar, causando paralisia de escolha para o iniciante. A separação em Bloco 1 (criar conta) + Bloco 2 (conectar existente) com hierarquia visual distinta resolve. [uniswap suas-posicoes-05 § Fricção 1 — 2 CTAs sem hierarquia clara]
Cards educacionais por nível (Card A para iniciante + Card B para intermediário) — Uniswap usa Fornecer liquidez em protocolos diferentes e Hooks no v4, ambos com framing de power user na exata tela onde público é 100% iniciante. [uniswap suas-posicoes-05 § Fricção 2 — cards com framing de power user] [uniswap consolidado suas-posicoes § Fricção 3 — conteúdo editorial voltado a power user]
Caminho para quem não tem wallet (Bloco 1 — criar conta) — Uniswap pressupõe wallet pré-existente; microcopy "Para visualizar posições, conecte sua carteira" abandona iniciante absoluto sem saída. [uniswap suas-posicoes-05 § Fricção 3 — microcopy pressupõe wallet pré-existente]
APR na sidebar com label contextual e caveat de IL — Uniswap exibe APR de 87% sem janela temporal nem caveat; FOMO para iniciante sem mental model de Impermanent Loss. [uniswap suas-posicoes-06 § Fricção 2 — APR sem caveat] [pancake-relatorio-final § Fricção 5 — risk signaling ausente]

🟡 Captura

Embedded wallet nativa (Bloco 1 — "Criar conta com e-mail") — nenhum DEX concorrente (Uniswap, PancakeSwap, KyberSwap, 1inch) incorpora criação de wallet. Iniciante absoluto abandona no pré-requisito externo (instalar MetaMask, salvar seed phrase, comprar cripto em exchange). Hipótese de diferenciação Kotai: Criar conta com e-mail cria smart wallet self-custody via Privy/Dynamic; on-ramp integrado permite aporte fiat (PIX) direto após criação. Usuário não-cripto vira usuário DeFi sem sair do produto, em menos de 5 min. [uniswap consolidado suas-posicoes § Oportunidade — embedded wallet nativa] [uniswap suas-posicoes-05 § Oportunidade — DEX com onboarding integrado] [pancake-relatorio-final § Insight — Defaults pró-iniciante]

⚪ Novo

Microcopy de custódia inline no Bloco 1 ("Kotai não tem acesso aos seus fundos. Você é o único dono.") — sem origem direta nos relatórios; não foi testado pelos concorrentes porque nenhum tem embedded wallet. Justificativa: o maior bloqueio de adoção de smart wallets por usuários BR é desconfiança de custódia. A frase resolve na origem antes que a dúvida apareça. Risco: pode gerar questionamentos ("como assim?" → o usuário pode querer entender melhor o modelo de custódia). Evidência a coletar: taxa de abandono no passo de criação de conta comparada com e sem o microcopy.
Hierarquia visual Bloco 1 > Bloco 2 (iniciante como perfil primário nesta tela) — decisão editorial sem referência direta nos relatórios. Justificativa: esta tela é acessada majoritariamente por quem não tem wallet; intermediário com wallet existente usa Conectar rapidamente independente de hierarquia visual. Risco: intermediário pode sentir que o produto "não é para ele". Mitigação: Bloco 2 sempre visível e acessível; não há conteúdo blocante. Evidência a coletar: proporção de cliques em Bloco 1 vs. Bloco 2.

7. Trade-offs e segunda ordem

Embedded wallet (Bloco 1) adiciona um provedor de infraestrutura externo (Privy, Dynamic ou equivalente) com custo ~$0,05/MAU e SLA próprio. Falha no provider bloqueia criação de conta por e-mail — fallback obrigatório: se Bloco 1 falhar, Bloco 2 (conectar wallet existente) ainda funciona. Kotai assume responsabilidade de UX de recuperação de conta (passkeys, social recovery) — é um compromisso de produto de longo prazo, não apenas de lançamento.

Cards educacionais estáticos (sem personalização) mantêm implementação simples mas servem o mesmo conteúdo para todos os visitantes desta tela. Se a base de usuários crescer, cards poderão ser personalizados por contexto (ex.: locale, referrer, parâmetro de campanha). Escopo inicial: estáticos.

Sidebar com APR badge de caveat exige threshold editorial (quando APR > 50% mostra caveat). Manutenção: se o mercado sistematicamente produzir APRs altos (período de bull market), o caveat aparecer em toda a lista perde força. Aceitar como custo — o iniciante BR/LatAm é o perfil que mais precisa desse sinal.

i18n: Bloco 1 com Criar conta com e-mail e microcopy de custódia têm copy PT-BR específico que precisa de equivalente em ES para LatAm fora do Brasil. Escopo inicial: PT-BR; adicionar ES como segunda iteração.

Conflito de pilar resolvido: Pilar 1 (verbo de intenção) vs. Pilar 3 (defesa em camadas). O Bloco 1 usa linguagem de ação ("Criar conta") em vez de vocabulário técnico ("Smart wallet"), mas introduz um novo fluxo de autenticação não-Web3-convencional. Prioridade: Pilar 1 — usuário entende o que vai fazer ("criar conta") antes de entender o mecanismo técnico por trás. A custódia é explicada no subtexto, não no CTA.

Tela 06 — Suas Posições: Hub conectado, zero posições (empty state canônico)

1. Função da tela

É o hub principal de gestão de posições no estado em que o usuário conectou a carteira mas ainda não tem nenhuma posição de liquidez ativa — a primeira impressão da seção para quem acabou de conectar. Resolve o problema de "o que faço agora?" para o iniciante que chegou aqui sem saber por onde começar, e o problema de "onde estão minhas posições?" para quem tem histórico mas está vendo lista vazia por filtro ou por posições v2 legadas.

2. Componentes / elementos

Estruturais

2.1 Header global

Tabs: Negociar · Explorar · Ganhar rendimento ✓ · Portfólio
Endereço encurtado da carteira conectada (ex.: 0xd09B…618a) + menu de ações no canto superior direito

2.2 Bloco de boas-vindas / rewards (condicional — componente central) Este bloco substitui o padrão da indústria de exibir 0 UNI Rewards / Recolher recompensas (disabled) que ocupa 30% do espaço útil comunicando "você não interagiu ainda" para o iniciante.

Estado A — count(posições) == 0 (este estado):

Fundo: card com cor de destaque suave (não alarme)
Título: Bem-vindo ao hub de posições
Corpo: "Adicione liquidez em um pool para começar a ganhar com as taxas de cada operação realizada por outros usuários."
CTA inline: Explorar pools recomendadas → (link, não botão cheio — não compete com o CTA primário abaixo)

Estado B — count(posições) > 0 (referência para implementação):

Exibe o bloco de rewards normalmente: valor acumulado + CTA Recolher recompensas (habilitado ou disabled conforme saldo)

2.3 Banner de detecção de posições v2 legadas (condicional) Renderizado apenas se a query on-chain detectar NFT v2 na carteira conectada. Posição no layout: imediatamente acima da toolbar de filtros (máxima visibilidade).

Cor: amarelo/âmbar (atenção, não erro)
Ícone: ! (atenção)
Texto: "Detectamos posições de liquidez antigas (v2) nesta carteira. Elas não aparecem na lista abaixo automaticamente."
CTA: Importar posições agora (botão outline; ação de importação)
Dismiss: × (dismissível, com estado persistido por carteira para não reaparecer)
Se ausência de NFT v2 detectada: componente inteiramente ausente do DOM (nenhum link de rodapé "Importar v2")

2.4 Toolbar de filtros

+ Nova posição (split button com chevron — dropdown de tipo de posição)
- Dropdown: Posição simples (full range) · Posição com range (concentrada) · Posição com hooks (avançado) — rótulos por outcome, não por versão técnica
- Badge Recomendado na opção de range concentrado
Status v · Protocolo v · Rede v (filtros com badge numérico quando diferente do default)

2.5 Empty state prescritivo (componente principal — estrutural) Este é o coração da tela e o ponto de maior diferenciação.

Sub-estado A — count(posições, ignorando filtros) == 0 e saldos da wallet conhecidos:

Card central com leitura de saldo:

Título: Sugestão para sua primeira posição
Corpo: "Você tem [R$ X em USDC] e [R$ Y em ETH]. Pool sugerida: USDC/ETH · 0,05% fee · range conservador."
- Linha de APR: APR de fees (30d): 4,89% + chip Verifique risco de IL (link para educação sobre Impermanent Loss)
- Linha de rede: Rede recomendada: Base — gas ~R$ 0,05
CTA primário: Criar com essa configuração (botão cheio) — pré-configura par + fee tier + range conservador (±20%) no fluxo de criação de posição
CTA secundário: Personalizar configuração (link) — vai para o fluxo de criação de posição sem pré-configuração
Abaixo do card: "Não sabe por onde começar? [Guia de liquidez em 3 min →]"

Sub-estado B — count(posições, ignorando filtros) == 0 e saldos indisponíveis ou zero:

Card central genérico (fallback):

Título: Adicione sua primeira posição de liquidez
Corpo: "Escolha um pool, defina um range de preço e comece a ganhar com as taxas de trading."
CTA primário: Explorar pools
CTA secundário: Criar posição manualmente
Abaixo: "Primeira vez? [Como funciona →]" (link para guia educacional)

Sub-estado C — count(posições, com filtros) == 0 mas count(posições, ignorando filtros) > 0:

Mensagem condicional (substitui os cards acima):

Título: Nenhuma posição corresponde aos filtros
Corpo: "Você tem [N] posição(ões) oculta(s) pelos filtros ativos."
CTA: Mostrar todas as posições (desfaz filtros e mostra tudo)
Microcopy: "Ou ajuste os filtros acima para ver diferentes combinações."

2.6 Sidebar de discovery (coluna direita — desktop)

Seção: Maiores pools por liquidez
Lista de 5–6 pools: par · APR de fees (30d) · Rede · chip de risco quando APR > 50%
Regras de exibição: APR exibido sempre como APR de fees (30d): X%; pools com APR > 50% acompanham chip discreto Rendimento alto — verifique IL
Link: Explorar todos os pools →
Seção: Saiba mais sobre liquidez — cards educacionais por nível (mesmos cards da Tela 05)

3. Regras de negócio

Detecção de posições v2

Ao conectar carteira, query assíncrona ao contrato NFT do protocolo v2 (ex.: Uniswap v2 pair factory ou equivalente Kotai). Se count(NFT v2) > 0: renderiza Banner 2.3. Se count(NFT v2) == 0: Banner 2.3 ausente, link de rodapé Importar v2 ausente.
Dismiss do banner persiste por (carteira, dispositivo) em localStorage — não reaparece mesmo após reconexão, a menos que novas posições v2 sejam detectadas após o dismiss.

Empty state prescritivo — leitura de saldos

Leitura de saldos da carteira acontece ao conectar (balanceOf on-chain ou provider de wallet).
Par sugerido: algoritmo editorial — par mais líquido (maior TVL nos últimos 30d na Kotai/rede selecionada) entre os tokens que o usuário já tem. Critério: liquidez(par) > $1M + fee tier dominante (>50% do volume).
Range sugerido: ±20% do preço atual como "range conservador" para a primeira posição.
Rede sugerida: a que tem o menor custo de gas entre as redes onde o par existe e o usuário tem saldo.
Se algoritmo não encontrar par (saldo de apenas 1 token ou tokens sem pool na Kotai): cai para Sub-estado B.
A sugestão é editorial — exibe critérios no tooltip i ao lado do card: "Sugerimos este pool por ter alta liquidez, fee tier com maior volume e ser adequado para posição conservadora. [Ver como escolhemos →]"

Filtros e empty state condicional

Quando filtros estão ativos e a lista é vazia: antes de renderizar empty state, query sem filtros conta posições totais.
Se count(com filtros) == 0 e count(sem filtros) > 0 → Sub-estado C.
Se count(sem filtros) == 0 → Sub-estado A ou B (conforme saldos).

Dropdown de nova posição

Opções por outcome (não por versão técnica):
- Posição simples (full range) → redireciona para criação com full range selecionado (v2/equivalente)
- Posição com range (concentrada) → range manual (v3/equivalente); badge Recomendado
- Posição com hooks (avançado) → modo avançado; badge Avançado + microcopy "Requer familiaridade com hooks."
Clique direto no botão + Nova posição (sem chevron) → abre Posição com range diretamente. Conflito de pilar documentado: Pilar 2 (default contextual — herança consciente do split button Uniswap onde v3 é o default) vs. target iniciante-first. Resolução: em Sub-estado A, o iniciante usa o CTA prescritivo Criar com essa configuração, não o split button. O split button é acionado por quem já decidiu criar manualmente e tem intenção explícita; nesse contexto, "range concentrado" + badge Recomendado é o produto adequado. O iniciante que nunca clicou no split button não é penalizado. [uniswap consolidado suas-posicoes § Insight — Defaults sensatos que servem todos os perfis]

Bloco de boas-vindas (Estado A)

Renderiza quando count(posições) == 0 E session.isFirstVisit == true (ou sempre no Estado A, independente de first visit — decisão de produto: mostra sempre em zero posições para servir como guia mesmo em retornos)
Não exibe 0 Recompensas ganhas + Recolher (disabled) — esse bloco só aparece quando há histórico de posições (Estado B)

4. Estados não-triviais

Vazio — zero posições, saldos desconhecidos (wallet sem saldo on-chain)

Empty state Sub-estado B (genérico): guia de "como começar" sem prescrição de par.

Vazio — zero posições, saldos conhecidos

Empty state Sub-estado A (prescritivo): sugestão baseada em saldo.

Vazio — zero posições por filtro (posições existem mas foram filtradas)

Empty state Sub-estado C (condicional): "Você tem N posição(ões) oculta(s)." + Mostrar todas.

Loading — carregando posições

Skeleton de cards de posição na área da lista.
Bloco de boas-vindas renderiza imediatamente (não depende de dados de posições para o texto estático).
Sidebar renderiza com skeleton enquanto pools carregam.

Loading — leitura de saldos para prescrição

Sub-estado A substitui o card prescritivo por placeholder: "Analisando sua carteira…" com spinner pequeno.
Se saldos não chegarem em 3s: fallback para Sub-estado B (genérico).

Erro — falha ao carregar posições

Área da lista exibe: "Não foi possível carregar suas posições." + Tentar novamente
Bloco de boas-vindas e sidebar não são afetados (dados independentes).

Erro — falha na query de posições v2

Banner v2 não renderiza (silêncio; não exibe erro de detecção — não alarmar por falha de detecção opcional).

Parcial — conexão EVM ok, outra rede (ex.: Solana) falhou

Banner inline no topo da lista: "Conectado à rede [X]. Posições em [Solana] não estão disponíveis agora. [Reconectar Solana]"
Lista exibe posições EVM normalmente.

Rede errada (wallet em rede sem suporte)

Banner no topo: "Sua carteira está em uma rede não suportada. Troque para [rede recomendada] para ver suas posições."
Lista vazia com orientação.

Sucesso — importação de posições v2 concluída

Banner verde temporário (3s auto-dismiss): "Posições importadas com sucesso. Elas já aparecem na lista."
Banner amarelo de v2 some do layout após importação.

Sucesso — posição criada (retorno do fluxo de criação)

Primeira posição aparece na lista; bloco de boas-vindas transita para Estado B (rewards block) com animação suave.

5. Microcopy crítico

Bloco de boas-vindas (Estado A)

Título: Bem-vindo ao hub de posições
Corpo: "Adicione liquidez em um pool para começar a ganhar com as taxas de cada operação realizada por outros usuários."
CTA inline: Explorar pools recomendadas →

Empty state Sub-estado A (prescritivo)

Título: Sugestão para sua primeira posição
Corpo (template): "Você tem [valor token A] e [valor token B]. Pool sugerida: [Par] · [fee tier] · range conservador."
APR: APR de fees (30d): X%
Chip: Verifique risco de IL (link)
Rede: Rede recomendada: [Nome] — gas ~R$ X
CTA primário: Criar com essa configuração
CTA secundário: Personalizar configuração
Abaixo: "Não sabe por onde começar? [Guia de liquidez em 3 min →]"
Tooltip i na sugestão: "Sugerimos este pool por ter alta liquidez e fee tier dominante. [Ver como escolhemos →]"

Empty state Sub-estado B (genérico)

Título: Adicione sua primeira posição de liquidez
Corpo: "Escolha um pool, defina um range de preço e comece a ganhar com as taxas de trading."
CTA primário: Explorar pools
CTA secundário: Criar posição manualmente
Abaixo: "Primeira vez? [Como funciona →]"

Empty state Sub-estado C (filtro escondeu posições)

Título: Nenhuma posição corresponde aos filtros
Corpo: "Você tem [N] posição(ões) oculta(s) pelos filtros ativos."
CTA: Mostrar todas as posições
Microcopy: "Ou ajuste os filtros acima para ver diferentes combinações."

Banner de posições v2

Texto: "Detectamos posições de liquidez antigas (v2) nesta carteira. Elas não aparecem na lista abaixo automaticamente."
CTA: Importar posições agora

Dropdown "Nova posição"

Posição simples (full range) — "Deposita em toda a faixa de preço. Simples, sem necessidade de acompanhamento."
Posição com range (concentrada) + badge Recomendado — "Concentra liquidez em um range. Maior potencial de fees, exige acompanhamento."
Posição com hooks (avançado) + badge Avançado — "Adiciona lógica customizada. Requer familiaridade com hooks."

APR na sidebar

Label: APR de fees (30d): X%
Chip de alto rendimento: Rendimento alto — verifique IL

Estado parcial (conexão parcial)

"Conectado à rede [X]. Posições em [Rede Y] não estão disponíveis agora." + Reconectar [Y]

Rede errada

"Sua carteira está em uma rede não suportada. Troque para [rede recomendada] para ver suas posições."

Sucesso importação v2

"Posições importadas com sucesso. Elas já aparecem na lista."

6. Rastreabilidade obrigatória

🟢 Herdado

Layout em 3 zonas (header de status / toolbar+lista / sidebar discovery) — hierarquia clara entre patrimônio pessoal e descoberta pública. [uniswap suas-posicoes-06 § Insight 1]
Banner dismissável para comportamento de default não óbvio (posições fechadas ocultas, posições v2 não exibidas) — produto anuncia o que escondeu em vez de silenciar. [uniswap suas-posicoes-06 § Insight 2]
Sidebar com APRs reais + educação (combinação de inspiração quantitativa + qualitativa) — serve iniciante e intermediário simultaneamente. [uniswap suas-posicoes-06 § Insight 3]
APRs sem ranking artificial — discovery mostra pools variados sem curadoria de conversão. [uniswap suas-posicoes-06 § Insight 4]
Defaults agregados respeitam modelo mental — Todas as redes e Todos os protocolos como default; complexidade técnica como filtro, não portão. [uniswap-relatorio-final § Defaults agregados]
Split button + Nova posição: clique direto → default recomendado; chevron → dropdown com opções — iniciante nunca precisa ver o dropdown para agir; avançado tem acesso sem fragmentar UI. Padrão validado no Uniswap. [uniswap consolidado suas-posicoes § Insight — Defaults sensatos que servem todos os perfis]

🔴 Corrige

Empty state condicional distingue "sem posição" de "filtro escondeu posições" — Uniswap exibe Nenhuma posição encontrada para ambos os casos; usuário com posições fechadas filtradas pode achar que perdeu posições. Sub-estado C com contagem de posições ocultas + CTA Mostrar todas resolve ambiguidade. [uniswap suas-posicoes-06 § Fricção 1] [uniswap consolidado suas-posicoes § Fricção 2 — empty state ambíguo]
APR na sidebar com janela temporal e caveat de IL — Uniswap exibe 87,74% APR sem (30d) e sem caveat de Impermanent Loss; gatilho de FOMO para iniciante. Label APR de fees (30d) + chip Rendimento alto — verifique IL endereçam. [uniswap suas-posicoes-06 § Fricção 2] [uniswap-relatorio-final § Fricção 6 — métricas DeFi sem decomposição]
Detecção proativa de posições v2 (banner amarelo) em vez de link de rodapé — Uniswap relegava Importar posições v2 a microcopy em rodapé; usuário com NFT v2 via empty state e podia achar que perdeu posição. Detecção on-chain + banner amarelo no topo resolve. [uniswap suas-posicoes-06 § Fricção 3 — importar v2 escondido]
Bloco de boas-vindas condicional em vez de 0 UNI Rewards / Recolher (disabled) — header de rewards zerado em wallet sem histórico comunica "produto projetado para quem já tem histórico". Substituição por bloco de onboarding quando count(posições) == 0. [uniswap consolidado suas-posicoes § Fricção 4 — header rewards zerado] [uniswap suas-posicoes-06 § Observação — 5ª aparição do header inadequado]
Labels de tipo de posição por outcome (Posição simples / com range / com hooks) em vez de versão técnica (v2/v3/v4) no dropdown de nova posição — léxico de protocolo exposto como primeira decisão sem tradução. [uniswap consolidado suas-posicoes § Fricção 1 — versionamento exposto] [pancake-relatorio-final § Fricção 1 — léxico de protocolo] [uniswap-relatorio-final § Fricção 1]

🟡 Captura

Empty state prescritivo baseado em saldo da wallet — todos os concorrentes (Uniswap, PancakeSwap, KyberSwap) têm empty state genérico (Crie uma posição para começar). Hipótese de diferenciação Kotai: ler saldos on-chain da wallet ao conectar e exibir "Você tem R$ X em USDC e R$ Y em ETH — pool sugerida: USDC/ETH 0,05%, range conservador" com CTA de criação pré-configurada. Converte empty state de placeholder em assistente de onboarding. [uniswap consolidado suas-posicoes § Oportunidade — empty state prescritivo] [uniswap suas-posicoes-06 § Oportunidade — "primeira posição sugerida"] [pancake-relatorio-final § Insight 1 — defaults pró-iniciante]
Dropdown de nova posição com rótulos de outcome + badge Recomendado — todos os concorrentes expõem versão técnica no dropdown de criação (v2/v3/v4). Hipótese: rótulo por outcome (Posição com range) é compreensível sem conhecimento prévio de versão de protocolo; badge Recomendado resolve a decisão para 90% dos iniciantes. [uniswap consolidado suas-posicoes § Oportunidade — versionamento → outcome]

⚪ Novo

Bloco de boas-vindas visível em todas as sessões com count(posições) == 0 (não só na primeira visita) — sem origem direta. Justificativa: usuário que conectou uma nova carteira vazia em sessão posterior não deve ver 0 UNI Rewards como se fosse retorno ao produto; o bloco de onboarding comunica o estado correto independente de histórico de sessão. Risco: pode parecer repetitivo para usuário que visita com frequência sem criar posições. Mitigação: o bloco é curto (título + 1 frase + link); não bloqueia acesso à toolbar/filtros. Evidência a coletar: % de usuários que clicam no link do bloco de boas-vindas vs. CTAs do empty state.
Detecção de saldo para prescrição com fallback em 3s — timeout de 3 segundos para fallback ao Sub-estado B genérico se saldos não chegarem. Sem referência direta nos relatórios. Justificativa: leitura de saldo on-chain pode demorar em RPCs congestionados; Sub-estado B é melhor que tela em estado de loading prolongado. Custo: usuário com saldo em RPC lento sempre vê o Sub-estado B mesmo tendo saldo. Aceitar por agora; refinar com percentil de latência de RPC em produção.

7. Trade-offs e segunda ordem

Empty state prescritivo com leitura de saldo exige: query on-chain de balanceOf por token + algoritmo editorial de seleção de par + atualização de sugestão quando saldo muda. Componente tem 3 sub-estados + fallback. Custo de implementação é médio; custo de manutenção editorial (critérios de sugestão) é contínuo e precisa de dono de produto. Ganho: converte o estado de maior abandono em assistente de primeira posição.

Detecção de posições v2 exige query ao contrato NFT v2 ao conectar — custo de latência ~200–500ms na primeira conexão. Se o produto não suportar protocolo v2, este componente é irrelevante e deve ser removido. Implementar condicionalmente por protocolo suportado.

Empty state condicional (Sub-estado C) exige duas queries: lista com filtros ativos + count sem filtros. Segunda query pode ser cacheada da request original (paginação sem filtros já acontece ao carregar a tela). Overhead mínimo se a arquitetura de dados separar "count total" de "count filtrado" na mesma response.

Bloco de boas-vindas condicional exige lógica de renderização baseada em count(posições). Sincronizado com a query da lista — se a lista retornar count == 0, bloco renderiza; se retornar count > 0, bloco some. Risco: flash de conteúdo (bloco aparece antes da lista carregar e some depois). Mitigação: skeleton da lista carrega junto com bloco para evitar layout shift.

i18n: Sub-estado A tem template de string com interpolação de valores monetários — _"Você tem [valor token A] e [valor token B]."_ — exige pluralização e formatação numérica por locale. Formato numérico: R$ 1.250,00 para PT-BR; USD 1,250.00 para EN. Implementar com biblioteca de i18n que suporte interpolação segura (sem concatenação de string manual).

Conflito de pilar resolvido (Pilar 2 vs. Pilar 4): Pilar 2 (CTA dinâmico + defaults contextual) pede que o empty state seja personalizado com base no contexto do usuário (saldo). Pilar 4 (educação contextual + transparência) pede que a sugestão seja acompanhada de contexto pedagógico (explicar IL, explicar range, explicar fee tier). A tensão é entre tornar o CTA prescritivo (Criar com essa configuração) e ser pedagógico o suficiente para que o usuário compreenda o que está confirmando. Resolução: CTA prescritivo permanece, mas acompanhado de bullets de contexto (APR de fees (30d): X% + Verifique risco de IL + tooltip de critérios de seleção). Pilar 2 ganha o CTA; Pilar 4 ganha o contexto inline. Nenhum modal adicional obrigatório antes do CTA (A3 — solução pior que o problema).

Suas Posições — Tela 01: Entrada sem carteira

1. Função da tela

Converte o visitante sem carteira que chega ao hub de liquidez pela primeira vez — eliminando o pré-requisito de wallet pré-existente e servindo conteúdo educacional calibrado para o iniciante absoluto, não para power user. Perfil-foco: iniciante absoluto (sem wallet prévia); secundariamente, explorador anônimo que ainda não decidiu se conecta.

2. Componentes / elementos

Estrutural — define o paradigma da tela:

2.1 Cabeçalho contextual

H1: "Suas posições de liquidez"
Subtítulo: "Visualize e gerencie onde seu dinheiro trabalha por você."
Bloco de rendimentos ausente aqui (condicional — aparece apenas quando count(posições) > 0; ver T02 e T03).

2.2 Bloco de acesso bifurcado (hero)

CTA primário: "Entrar com email ou Google" — inicia criação de smart wallet self-custody (Privy / Dynamic); passkeys, sem frase secreta.
Microcopy de custódia imediatamente abaixo do CTA primário: "Sem frase secreta. Seus fundos, sob seu controle."
CTA secundário: "Conectar carteira existente" — abre painel master/detail de seleção de wallet (componente compartilhado do fluxo Conectar Carteira).
Link de exploração passiva abaixo dos dois CTAs (peso visual baixo): "Ainda explorando? Continue sem conectar →"

2.3 Cards educacionais por nível (empilhados, iniciante primeiro)

Card A — iniciante: título "Primeira vez? Como funciona ganhar com liquidez", subtítulo "Leitura de 3 min — sem jargão técnico", tag "Para começar"
Card B — intermediário: título "Como funcionam pools de liquidez concentrada", tag "Para quem já usa DeFi"
Hierarquia visual explícita: Card A em destaque, Card B em secondary.

2.4 Sidebar de discovery pública (direita; independente de autenticação)

Título: "Pools em destaque"
Lista de 3–5 pools ordenadas por Volume 7d desc (label explícito "Mais ativas").
Cada item: par de tokens + APR label "~X% ao ano, estimativa (30d, sem IL) ⓘ" + badge de atividade.
Rodapé da sidebar: "Selecionadas por volume 7d e verificação de tokens [ver critérios]"
CTA da sidebar: "Explorar todos os pools →"

Cosmético — polish para segunda fase:

Ícone ilustrativo na área hero (símbolo de acesso, sem wallet = cadeado aberto — a definir em visual design).
Animação de entrada do bloco bifurcado (fade-in discreto).

3. Regras de negócio

CTA primário email: ao clicar, abre modal de criação de smart wallet. Após sucesso com saldo zero → redirect para T03 (empty state prescritivo). Após funding + primeira posição → redirect para T02.
CTA secundário wallet: abre painel master/detail de seleção de wallet. Após conexão bem-sucedida:
- count(posições) > 0 → T02
- count(posições) == 0 → T03
Link "Continue sem conectar": navega para exploração de pools sem autenticação (equivalente a clicar em "Explorar todos os pools →" na sidebar). Visível apenas neste estado; após conectar, desaparece.
Sidebar: carregada sem autenticação. Pools ordenadas por Volume 7d desc. APR sempre com label correto e janela temporal. Falha de dados → dados em cache com badge "Dados podem estar desatualizados" no rodapé da sidebar.
Cards educacionais: clicáveis. Card A abre guia para iniciante (sem jargão, linguagem de outcome). Card B abre conteúdo técnico de LP concentrado. Ambos abrem em modal ou nova aba dependendo do suporte de conteúdo — a definir.
Detecção automática: se o usuário já tem wallet instalada detectada no navegador (MetaMask, Rabby etc.), o CTA secundário "Conectar carteira existente" recebe badge discreto "Detectamos [Wallet]" — reduz fricção de escolha sem remover o CTA primário de email.

4. Estados não-triviais

Estado	Comportamento
Padrão (sem wallet)	Bloco bifurcado + cards educacionais + sidebar
Loading email	Botão muda para "Criando sua conta..." com spinner; layout preservado; sem redirecionamento prematuro
Loading wallet	Painel master/detail abre como overlay; tela fica visível atrás
Erro de criação email	Mensagem inline abaixo do CTA primário: "Não foi possível criar sua conta. Tente novamente ou conecte uma carteira existente."
Erro de conexão wallet	Tratado dentro do componente de Conectar Carteira (fora do escopo desta tela)
Sidebar em erro	Pools em cache com badge "Dados podem estar desatualizados" no rodapé; layout não quebra
Mobile	CTA primário e secundário empilhados verticalmente; link explorador abaixo; sidebar colapsa para carrossel horizontal de cards de pool abaixo dos cards educacionais
Wallet detectada	Badge "Detectamos [Wallet]" no CTA secundário — não altera hierarquia de CTAs

5. Microcopy crítico

Elemento	Texto PT-BR
H1	"Suas posições de liquidez"
Subtítulo	"Visualize e gerencie onde seu dinheiro trabalha por você."
CTA primário	"Entrar com email ou Google"
Microcopy custódia	"Sem frase secreta. Seus fundos, sob seu controle."
CTA secundário	"Conectar carteira existente"
Badge carteira detectada	"Detectamos [Wallet] no seu navegador"
Link explorador	"Ainda explorando? Continue sem conectar →"
Card A título	"Primeira vez? Como funciona ganhar com liquidez"
Card A subtítulo	"Leitura de 3 min — sem jargão técnico"
Card A tag	"Para começar"
Card B título	"Como funcionam pools de liquidez concentrada"
Card B tag	"Para quem já usa DeFi"
Sidebar título	"Pools em destaque"
Sidebar APR	"~X% ao ano, estimativa (30d, sem IL) ⓘ"
Tooltip APR	"Estimativa baseada nas tarifas coletadas pelos provedores desta pool nos últimos 30 dias. Não inclui Impermanent Loss — seu retorno real pode ser maior ou menor."
Sidebar rodapé	"Selecionadas por volume 7d [ver critérios]"
Sidebar CTA	"Explorar todos os pools →"
Loading CTA primário	"Criando sua conta..."
Erro criação email	"Não foi possível criar sua conta. Tente novamente ou conecte uma carteira existente."

6. Rastreabilidade obrigatória

🟢 Herdado

Sidebar de discovery pública independente de autenticação — decisão validada explicitamente: "Discovery não exige identidade. Esquerda da tela = patrimônio (privado); direita = mercado (público, independente de quem é o usuário)." [uniswap suas-posicoes § Separação visual entre gestão pessoal e discovery pública — telas 5 e 6]
Empty state como espaço editorial com cards educacionais contextuais — em vez de placeholder mudo, as telas de pré-conexão do Uniswap já usam cards educacionais. A Kotai herda o padrão e o corrige (ver 🔴). [uniswap suas-posicoes § Empty state como espaço editorial — telas 1, 5 e 6]
Layout dois painéis: ação à esquerda (privado) / contexto à direita (público) — padrão master/detail validado em múltiplos fluxos do Pancake. [pancake-final § Painel master/detail preservando contexto + progressive disclosure]
CTA de conexão como ação primária de entrada — convenção válida; herança consciente de convenção de mercado (A8: mudar sem motivo quebraria reconhecimento). O CTA primário aqui é estendido (email + wallet), não substituído. [uniswap suas-posicoes-05 — convenção de "Conectar carteira" como CTA de entrada]
Microcopy preventiva que declara o que NÃO acontece — padrão Uniswap de frases que antecipam o medo ("sua frase de recuperação NÃO será removida"). Adaptado aqui para smart wallet: "Sem frase secreta. Seus fundos, sob seu controle." [uniswap-final § Copy preventiva que declara o porquê / o que NÃO acontece]

🔴 Corrige

Microcopy que assume wallet pré-existente — Uniswap T05: "Para visualizar posições e recompensas, conecte sua carteira" pressupõe que o usuário já concluiu a jornada externa de instalação de wallet. Iniciante absoluto abandona por não entender o pré-requisito. [uniswap suas-posicoes § Fricção pontual — tela 5: microcopy pressupõe pré-requisito de wallet]
Cards educacionais para power user nas telas de maior presença de iniciante — Uniswap T05 exibe "Fornecer liquidez em protocolos diferentes" e "Hooks no v4": conteúdo pressupõe familiaridade com DeFi no exato estado onde 100% do público nunca usou. [uniswap suas-posicoes § Fricção estrutural: conteúdo editorial voltado a power user — telas 5 e 6]
CTA único de "Conectar carteira" exclui o maior pool de usuários potenciais — iniciante absoluto não tem wallet; fluxo de criação externo (instalar MetaMask, backup de seed, comprar cripto, transferir) elimina a maioria dos candidatos antes do produto ter chance de retê-los. [uniswap suas-posicoes § Oportunidade: onboarding sem pré-requisito de wallet — tela 5]

🟡 Captura

Embedded wallet nativa via email/social (Privy/Dynamic) [uniswap suas-posicoes § Oportunidade: onboarding sem pré-requisito de wallet — tela 5] — passa nas 4 perguntas-teste: (1) ✓ nenhum DEX incorpora criação de wallet; (2) ✓ afeta iniciante absoluto, target principal; (3) ✓ tecnicamente factível via Privy/Dynamic; (4) ✓ ganho imediatamente perceptível. Hipótese concreta: CTA "Entrar com email ou Google" como primário aumenta conversão de visitante sem wallet em usuário ativo. Evidência a coletar: taxa de criação via email vs conexão EOA nas primeiras 4 semanas.
Cards educacionais bifurcados por nível [uniswap suas-posicoes § Fricção estrutural: conteúdo editorial voltado a power user — alternativa concreta] — a alternativa concreta do consolidado propõe exatamente "dois cards por nível de familiaridade". A Kotai implementa. Hipótese: Card A ("3 min, sem jargão") converte leitura em primeira ação; Card B serve intermediário sem excluir o iniciante. Evidência a coletar: CTR por card segmentado por perfil de usuário (sem wallet / EOA nova / EOA com histórico).

⚪ Novo

Microcopy de custódia inline ("Sem frase secreta. Seus fundos, sob seu controle.") abaixo do CTA email. Sem origem direta nos relatórios analisados. Justificativa: o modelo smart wallet self-custody é radicalmente novo para o target BR vindo de CEX; o maior risco de abandono é confusão com custódia centralizada ("será que a Kotai guarda meu dinheiro?"). A frase trata esse medo no momento de decisão, antes que vire razão de abandono. Evidência a coletar: taxa de abandono no CTA email antes/depois do microcopy; qualidade de perguntas no suporte sobre custódia.
Link "Ainda explorando? Continue sem conectar →" — sem equivalente direto nos DEXs analisados. Justificativa: explorador anônimo que não quer se comprometer abandona quando o único caminho visível é autenticação. O link baixa a barreira sem custo (sidebar já era pública). Risco: dilui urgência de conectar. Mitigação: peso visual baixo (texto-link, não botão), posicionado abaixo de ambos os CTAs.

7. Trade-offs e segunda ordem

Custo de embedded wallet provider (~$0,05/MAU via Privy): à medida que a base cresce, torna-se custo recorrente. Definir pricing antes da decisão de arquitetura; avaliar DynamicXYZ como alternativa com tier gratuito.
UX de recuperação de smart wallet: a tela promete "Sem frase secreta" — o produto precisa de resposta concreta para "e se eu perder acesso ao email/Google?" (passkeys, social recovery, número de telefone). Esse fluxo precisa existir antes do lançamento. Esta tela não entra em produção sem o fluxo de recuperação completo.
Dois modelos de custódia na mesma tela: smart wallet (email) e EOA (carteira própria) têm modelos de segurança radicalmente diferentes. O microcopy de custódia cobre o risco de confusão para o email; a diferenciação completa dos dois modelos é responsabilidade do fluxo Conectar Carteira (painel master/detail com microcopy de custódia por card).
i18n: todo o microcopy desta tela é PT-BR. Qualquer SDK de terceiro (Privy/Dynamic, OAuth) precisa ter locale PT-BR forçado antes do lançamento — vício sistêmico dos dois concorrentes analisados.
Sidebar com dados de pool: requer feed de Volume 7d atualizado. Latência de RPC/indexer não deve quebrar a tela; dados em cache com badge de desatualização são a cobertura mínima aceitável.
Armadilha A3 checada: o CTA primário email não é solução pior que o problema. Adiciona um caminho, não uma barreira. A bifurcação é aditiva.
Armadilha A8 checada: o CTA de "Conectar carteira" não foi removido — foi mantido como secundário. A convenção de mercado é preservada; o primário email é extensão, não inversão.

Suas Posições — Tela 02: Hub principal com posições

1. Função da tela

Serve como hub central de gestão das posições de liquidez da wallet — lista todas as posições com status visual imediato, destaca o que precisa de ação, e expõe controles de filtragem em linguagem de outcome (não de versão de protocolo). Perfil-foco: iniciante e intermediário com ao menos uma posição ativa; é a tela de maior frequência de retorno do produto.

2. Componentes / elementos

Estrutural — define o paradigma da tela:

2.1 Cabeçalho de rendimentos (condicional: só visível quando count(posições) > 0)

Label: "Rendimentos acumulados"
Valor: total de fees acumuladas, em BRL (destaque) + USD (secondary)
CTA: "Recolher rendimentos" — desabilitado (com microcopy de causa explícita) quando fees acumuladas < custo estimado de gas × 1,5
Badge de período: "Desde [data da primeira posição]" ou "Acumulado" — com tooltip explicando que o valor reflete fees ainda não resgatadas, não retorno total histórico

2.2 Chip de urgência (aparece antes da toolbar quando N > 0)

Label: "⚠ Precisa de ação (N)"
Visual: chip em laranja/âmbar (urgência, não erro; vermelho seria interpretado como falha do sistema)
Comportamento: clicar aplica filtro que exibe apenas posições com pelo menos um critério de urgência ativo. Clicar novamente remove o filtro.
Critérios de urgência (visíveis via tooltip + link "ver critérios"):
- Fora do range há >24h
- Fees acumuladas > 5× custo estimado de gas para recolher
- Exposição unilateral >80% (token A virou >90% da composição da posição)
Tooltip: texto completo dos critérios com link "ver critérios" para página de configurações onde os thresholds são ajustáveis

2.3 Toolbar de filtros

Busca inline — ícone de lupa sempre visível; expande no eixo horizontal ao clicar, preservando contexto da tabela. Label do input: "Buscar par..."
Tipo de provisão ▾ (renomeação de "Protocolo") — opções: "Simples (full range)" / "Concentrada (range manual)" / "Programável (hooks)"; todos ativos por default. Badge de estado ativo "(N)" quando difere do default, ex: "Tipo de provisão (2)"
Status ▾ — opções: "● Em range" / "● Fora do range" / "● Fechada"; "Em range" + "Fora do range" ativos por default ("Fechada" requer opt-in explícito). Badge de estado ativo quando difere do default.
Rede ▾ — "Todas as redes" por default. Label textual sempre visível ("Rede ▾"), não apenas ícone. Badge de estado ativo quando rede específica selecionada.

2.4 Lista de posições (cada posição como card)

Cada card contém:

Par: "USDC / ETH" com ícones dos dois tokens
Badge de tipo de provisão: "Simples" / "Concentrada" / "Programável" — tooltip no badge com nome técnico: "Simples: full range, sem gestão ativa (v2) | Concentrada: range manual, mais eficiência (v3) | Programável: com lógica customizada (v4)"
Status visual: dot colorido + label — "● Em range" (verde) / "● Fora do range" (vermelho) / "● Fechada" (cinza)
APR: "~X% ao ano ⓘ" — tooltip obrigatório com janela de cálculo e caveat de IL
Tarifas disponíveis: "Tarifas: R$ X,XX" — valor em BRL (destaque) + USD (secondary)
Gap fees/gas inline: "Recolher agora custa ~R$ Y,YY em gas" — abaixo do valor de tarifas; visível quando fees > gas (sugere ação) ou quando fees < gas × 2 (alerta custo)
Chip de urgência inline (laranja): aparece no card quando a posição tem critério de urgência ativo. Ex: "⚠ Fora do range há 2 dias — verifique" / "⚠ Tarifas > gas — considere recolher" / "⚠ Posição concentrada em [Token A]"
CTA inline: "Ver detalhes →"

Para posições Concentradas, elemento cosmético adicional:

Barra de posição relativa: indicador visual da posição do preço atual dentro ou fora do range configurado

2.5 CTA "Adicionar posição" (fixo topo-direito; FAB em mobile)

Split button: clique direto → abre fluxo criar-pool com Modo Concentrado (Recomendado) pré-selecionado
Clique no chevron: dropdown com "Posição simples (full range)" / "Posição concentrada (range manual) — Recomendado" / "Posição programável (hooks) — Avançado"
Sem exposição de v2/v3/v4 como opções primárias

2.6 Sidebar de discovery (direita; continuidade com T01 e T03)

"Pools em destaque" — idêntico às outras telas
Adicional quando relevante: "Você já tem posição nesta pool" como badge inline no item da sidebar

Cosmético:

Ordenação default da lista: posições com urgência primeiro, depois por valor da posição (TVL desc)
Paginação ou scroll infinito para carteiras com muitas posições (>20)
Data de criação da posição visível como tertiary info no card

3. Regras de negócio

Condicionalidade desta tela: renderizada quando count(posições da wallet) > 0. Se após aplicar filtro count cair a zero, exibir empty state condicional (não redirecionar para T03 — a wallet tem posições, estão só filtradas).
Chip de urgência: visível quando count(posições com critério ativo) > 0. Calculado client-side com dados de posição já carregados; não requer nova query on-chain. Ao clicar, aplica filtro implícito de urgência sobre os filtros já ativos (interseção, não substituição).
Badge de filtro ativo: cada botão exibe "(N)" onde N = count de opções selecionadas. Quando N = total das opções (default), sem badge — filtro que não filtra nada não anuncia que está "filtrando".
Empty state condicional (filtro oculta posições): se count(posições, sem filtros) > 0 E count(posições, com filtros) == 0 → exibir "Nenhuma posição corresponde aos filtros. Você tem X posições [Fechadas] ocultas. [Mostrar todas]". O label entre colchetes indica o filtro ativo responsável pelo ocultamento. Se count(posições, sem filtros) == 0 → redirecionar para T03.
CTA "Recolher rendimentos": bloqueado (disabled com microcopy de causa) quando fees acumuladas totais < custo estimado de gas × 1,5. Microcopy inline: "Gas estimado: R$ X,XX — aguarde acumular mais antes de recolher para compensar o custo." Quando desbloqueado → abre modal de confirmação de recolhimento (fora do escopo desta tela).
Split button "Adicionar posição": clique direto pré-seleciona Modo Concentrado porque é o modo com maior eficiência de capital para a maioria dos pares com liquidez ativa. Inicia criar-pool com par em branco. O chevron para Avançado (Programável) exibe badge "Avançado" — não deve ser apresentado como equivalente às outras opções.
APR exibido: APR da pool inteira (não da posição individual, que depende do range específico). Label sempre inclui a nota "(estimativa 30d, sem IL)". Tooltip explica a diferença entre APR da pool e retorno efetivo da posição.
Gap fees/gas inline: calculado client-side. Custo de gas estimado com base na rede da posição + preço de gas atual da rede. Se custo de gas indisponível (RPC com falha), a linha de gap é ocultada (não exibe "R$ 0,00").
Posição Concentrada fora do range: chip de urgência inline torna-se vermelho (não laranja) quando fora do range há >72h — escalada de urgência visual progressiva.

4. Estados não-triviais

Estado	Comportamento
Populado (N posições, 0 urgentes)	Hub completo: header rendimentos + toolbar + lista + sidebar
Com urgências (N posições, M urgentes)	Chip "⚠ Precisa de ação (M)" aparece antes da toolbar; M cards têm chip inline
Loading inicial	Skeleton de cards preservando estrutura completa (toolbar, lista, sidebar — todos em skeleton proporcionalmente correto)
Loading ao aplicar filtro	Lista em skeleton durante filtro; toolbar preserva estado visual; sidebar não recarrega
Filtro ocultando posições	Empty state condicional: "Nenhuma posição corresponde aos filtros. Você tem X posições [Fechadas] ocultas. [Mostrar todas]"
Rede errada	Banner sticky no topo (não sobrepõe o header): "Suas posições em [Ethereum] ficam indisponíveis nesta rede. [Trocar para Ethereum]"
Carteira desconectada	Redirect imediato para T01
Erro de carregamento de posições	Mensagem inline no lugar da lista: "Não conseguimos carregar suas posições. [Tentar novamente]" — toolbar e sidebar carregam independentemente
Após fechar a última posição	Redirect para T03 com toast: "Posição fechada com sucesso."
Mobile	Sidebar colapsa para seção inferior após a lista; chip de urgência vira banner full-width; filtros viram bottom sheet acionado por botão "Filtrar" fixo; FAB "+" substituindo split button; barra de posição relativa oculta (sem espaço)

5. Microcopy crítico

Elemento	Texto PT-BR
Header rendimentos	"Rendimentos acumulados"
Header período	"Desde [data]
Tooltip período	"Total de tarifas geradas pelas suas posições ainda não resgatadas. Não inclui posições já fechadas ou tarifas já recolhidas."
CTA recolher	"Recolher rendimentos"
CTA recolher (bloqueado)	"Recolher rendimentos" (disabled)
Tooltip recolher bloqueado	"Gas estimado: R$ X,XX. Aguarde acumular mais tarifas antes de recolher para compensar o custo."
Chip urgência	"⚠ Precisa de ação (N)"
Tooltip urgência	"Posições com: tarifas acumuladas maiores que 5× o gas para recolher, fora do range por mais de 24h, ou concentração em um único token acima de 80%. [Ver critérios]"
Filtro tipo	"Tipo de provisão ▾"
Tipo: simples	"Simples (full range)"
Tipo: concentrada	"Concentrada (range manual)"
Tipo: programável	"Programável (hooks)"
Tooltip badge tipo	"Simples: full range, sem gestão ativa (v2)
Filtro status	"Status ▾"
Status em range	"● Em range"
Status fora do range	"● Fora do range"
Status fechada	"● Fechada"
Filtro rede	"Rede ▾"
APR label	"~X% ao ano ⓘ"
Tooltip APR	"Estimativa baseada nas tarifas coletadas pelos provedores desta pool nos últimos 30 dias. Não inclui Impermanent Loss — seu retorno real pode ser maior ou menor."
Tarifas	"Tarifas: R$ X,XX"
Gap gas	"Recolher agora custa ~R$ Y,YY em gas"
Chip urgência — fora range	"⚠ Fora do range há X dias — verifique"
Chip urgência — fees/gas	"⚠ Tarifas > gas — considere recolher"
Chip urgência — unilateral	"⚠ Concentrado em [Token A] — verifique exposição"
CTA card	"Ver detalhes →"
CTA adicionar posição	"Adicionar posição"
Dropdown: simples	"Posição simples (full range)"
Dropdown: concentrada	"Posição concentrada (range manual) — Recomendado"
Dropdown: programável	"Posição programável (hooks) — Avançado"
Empty state filtrado	"Nenhuma posição corresponde aos filtros. Você tem X posições [Fechadas] ocultas. [Mostrar todas]"
Erro de carregamento	"Não conseguimos carregar suas posições. [Tentar novamente]"
Banner rede errada	"Suas posições em [Ethereum] ficam indisponíveis nesta rede. [Trocar para Ethereum]"
Busca placeholder	"Buscar par..."
Toast pós-fechamento	"Posição fechada com sucesso."

6. Rastreabilidade obrigatória

🟢 Herdado

Defaults de filtro que mostram tudo por padrão — filtro opt-in correto: usuário vê todas as posições relevantes sem precisar configurar; granularidade disponível sem obrigar. "Affordances de poder devem existir e ser acessíveis, mas nunca estar no caminho padrão." [uniswap suas-posicoes § Defaults sensatos — telas 1, 2, 3, 4]
Default "Em range + Fora do range" ativos por padrão — posição fora de range exige atenção e não deve ser escondida por default; "Fechada" como opt-in reconhece que maioria dos usuários quer ver posições ativas. [uniswap suas-posicoes § Pontos isolados, tela 2]
Semáforos visuais (dots coloridos) antes do label de status — reconhecimento imediato de estado sem leitura; elimina o decode textual puro. [uniswap suas-posicoes § Pontos isolados, tela 2]
Split button para CTA de criação — iniciante usa ação principal (clique direto) sem ver o dropdown de opções; avançado acessa o chevron. Insight do consolidado Uniswap: "o iniciante nunca vê o dropdown; o avançado nunca perde a opção." [uniswap suas-posicoes § Defaults sensatos — split button insight, tela 1]
Sidebar de discovery preservada em hub populado — separação visual entre gestão pessoal (esquerda) e discovery pública (direita) funciona igual com e sem posições. [uniswap suas-posicoes § Separação visual entre gestão e discovery — telas 5, 6]
Múltiplas representações do mesmo dado + equivalente BRL — todo token amount exibe equivalente BRL ao lado em momentos críticos (fees acumuladas, gap gas). [uniswap-final § Múltiplas representações do mesmo dado + bidirecionalidade]

🔴 Corrige

Filtros sem badge de estado ativo após fechar dropdown — usuário que desmarcou opção por engano não tem sinal visual de que o filtro está restrito. Corrigido com badge "(N)" por filtro quando difere do default. [uniswap suas-posicoes § Fricção cosmética: filtros sem indicador de estado ativo — telas 2 e 4]
Versionamento de protocolo ("v2 / v3 / v4") como label primário do filtro — iniciante não tem modelo mental para versão de protocolo; aprende decorando ("v3 é a boa") sem compreender por quê. Corrigido renomeando filtro para "Tipo de provisão" com labels por outcome (Simples / Concentrada / Programável); v2/v3/v4 relegados a tooltip. [uniswap suas-posicoes § Fricção estrutural: versionamento de protocolo exposto como primeira decisão — telas 1 e 3] + [pancake-final § Fricção 1 — Léxico de protocolo]
Empty state ambíguo entre "sem posição" e "filtro escondeu tudo" — "Nenhuma posição encontrada" é invariante, independente da causa; usuário com posições fechadas vê empty state e pode concluir que "as posições sumiram". Corrigido com empty state condicional: se count(posições, sem filtro) > 0, mostrar contador de posições ocultas + CTA de reset. [uniswap suas-posicoes § Fricção estrutural: empty state ambíguo — telas 2 e 6]
APR exibido sem caveat de IL e sem janela temporal — "87% Renda anual" sem "estimativa baseada em 7d, não inclui IL". Iniciante toma o número como promessa de retorno. Corrigido com label "~X% ao ano ⓘ" e tooltip obrigatório com janela + caveat. [uniswap suas-posicoes § Pontos isolados, tela 6 — APR sem caveat] + [uniswap-final § Fricção 6: métricas DeFi sem decomposição]
Filtro de rede sem label textual — inconsistência de affordance: filtros Status e Protocolo têm label textual; filtro de rede só ícone. Corrigido com label "Rede ▾" sempre visível. [uniswap suas-posicoes § Fricção cosmética: filtros sem indicador de estado ativo — tela 4]

🟡 Captura

Chip de urgência "Precisa de ação (N)" [uniswap suas-posicoes § Oportunidade: filtro de ação recomendada por urgência — tela 2] — 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 = investimento de produto; (4) ✓ usuário abre hub e imediatamente vê "3 posições precisam de ação". Hipótese concreta: converte painel de gestão passivo em assistente ativo — taxa de ação em posições urgentes aumenta vs baseline atual em concorrentes. Evidência a coletar: % de cliques no chip vs ação direta no card de posição urgente.
Versionamento → outcome na UI (renomeação de "Protocolo" para "Tipo de provisão") [uniswap suas-posicoes § Oportunidade: versionamento de protocolo → outcome na UI — tela 3 + família sistêmica] — hipótese: iniciante lê "Concentrada" e entende que é diferente de "Simples" sem precisar decorar v2/v3/v4; conhecimento transfere para outros DEXs que usam os mesmos conceitos. Trade-off: vocabulário paralelo ao da indústria; mitigado por badge no tooltip com nome técnico "Concentrada (v3)".

⚪ Novo

Gap fees vs gas inline no card de posição — sem origem direta nos relatórios. Uniswap mostra fees acumuladas; Pancake (visualizar-farm) mostra APR mas não o gap fees/gas em posição individual. Justificativa: a decisão de quando recolher fees é uma das ações mais frequentes e mais sub-ótimas do LP iniciante (recolhe cedo demais gastando mais em gas do que recebe, ou esquece e acumula passivamente). A comparação inline resolve sem exigir que o usuário calcule mentalmente. Risco: estimativa de gas pode estar errada em momentos de congestão. Mitigação: prefixo "~" explícito. Evidência a coletar: taxa de recolhimento em posições onde gap > 3× gas vs posições onde gap < 1× gas.
Ordenação default da lista por urgência primeiro, depois por valor — sem origem explícita nos relatórios. Justificativa: usuário com posições urgentes recebe a informação mais relevante no topo sem precisar aplicar o chip de urgência. Risco: usuário que quer ver suas maiores posições primeiro fica frustrado. Mitigação: opção de reordenação por valor disponível na toolbar (cosmético — segunda fase).

7. Trade-offs e segunda ordem

Modelo de urgência como opinião editorial: os três critérios têm thresholds que são decisões de produto (>24h fora de range, >5× gas, >80% unilateral). Usuário avançado pode discordar. Mitigação obrigatória: critérios visíveis via "ver critérios" e thresholds ajustáveis nas configurações (não ocultar a lógica). Risco de gaming: usuário que desativa critérios perde alertas legítimos.
Badge de filtro ativo exige count em tempo real: se a lista de posições for paginada, o counter "(N)" precisa refletir o total (não apenas a página atual) — requer query de count adicional sem filtro. Alternativa simples: count apenas das posições já carregadas, com ressalva "pelo menos X posições".
APR da pool vs retorno da posição individual: o APR exibido é da pool inteira com base em full-range. Posição Concentrada com range estreito pode ter APR muito diferente (maior ou menor) dependendo do posicionamento. O tooltip deve esclarecer isso explicitamente para evitar expectativa errada.
Recolhimento de rendimentos como modal separado: o CTA "Recolher rendimentos" do header abre um modal (out of scope desta tela). É preciso definir se o recolhimento é por pool, por posição ou global antes de implementar o modal — a arquitetura de recolhimento afeta diretamente como o valor do header é calculado.
Mobile e chip de urgência + toolbar de 4 itens: em viewport estreito (<375px), chip + toolbar de 4 filtros + busca não cabem na mesma linha. Decisão: chip como banner independente (linha acima da toolbar); toolbar com scroll horizontal; filtros individualmente acessíveis via "Filtrar" bottom sheet.
i18n: "Tipo de provisão", "Rendimentos acumulados", "Precisa de ação" não têm equivalentes diretos em EN técnico. Pipeline de tradução precisa de revisão humana para esses termos antes do lançamento em EN/ES.
Conflito Pilar 1 vs Pilar 4: Pilar 1 (naming system) exige renomear "Protocolo" → "Tipo de provisão"; Pilar 4 (educação contextual) pede tooltip com a equivalência técnica. Ambos são satisfeitos: label primário é "Tipo de provisão", tooltip de detalhe exibe "v2/v3/v4". Nenhum conflito residual.

Pools — Tela 1 — Landing "Ganhar rendimento" (catálogo + minhas posições)

Função da tela

Porta de entrada da seção de yield da Kotai. Atende dois usuários simultaneamente — o recorrente que vem ver "como estão minhas posições" e o iniciante que vem perguntar "onde posso ganhar rendimento provendo liquidez?". A tela precisa servir os dois sem subordinar um ao outro, com curadoria opinionada para o iniciante e atalho direto para o recorrente.

Foco principal: iniciante BR/LatAm chegando pela primeira vez ao conceito de LP, com intermediário recorrente como segundo público.

Componentes / elementos

Estrutural (define o paradigma da tela)

Hero contextual com verbo de intenção
- Título: "Ganhar rendimento" (não "Pools", não "Earn", não "Farms").
- Sub-hero: "Provea liquidez em pares de tokens e receba parte das taxas de cada troca feita no pool." — uma frase, conceito traduzido.
- Link discreto "Como funciona o rendimento?" ao lado, abre painel lateral pedagógico (não modal, não nova página).
Segmento primário por mecânica de produto (controle único, peso forte)
- "Pares de liquidez" (ativa por default) | "Stake de token único"
- Mecânicas radicalmente distintas (dual-asset com risco de IL vs. single-asset sem IL) viram segmento explícito, não link discreto enterrado. Cada segmento é uma página com seu próprio catálogo.
Sub-tab de visão dentro do segmento ativo
- "Recomendados" (default) | "Catálogo" | "Minhas posições" (badge com contagem quando ≥1)
- Default "Recomendados" — não "Minhas posições" como na Pancake (que assume recorrente) nem "Catálogo cru" como na Uniswap (que assume sofisticação). Iniciante chega no caminho recomendado; recorrente clica em "Minhas posições" e fica nessa visão por sessão (persistência por device).
Bloco "Recomendados" — pool finder por perfil de risco
- Três cartões horizontais com pré-seleção curada:
  - "Conservador" — par de stablecoins (ex: USDC/USDT). Rendimento estimado menor, risco de IL próximo de zero.
  - "Moderado" — par blue-chip + stable (ex: ETH/USDC). Rendimento médio, risco de IL moderado e bem documentado.
  - "Agressivo" — par com ativo volátil. Rendimento potencial alto, risco de IL alto.
- Cada cartão mostra: par, "Rendimento estimado (7d, sem IL) ⓘ", TVL, range de fee tier sugerido, e uma frase de justificativa de risco ("Stablecoins têm IL próximo de zero — bom para quem quer aprender LP" / "Pares voláteis podem ter IL maior que o rendimento se o preço se mover muito").
- CTA por cartão: "Ver detalhes" (não "Aportar" — decisão de aporte fica para a tela de detalhe do pool, onde o usuário vê range, simulação de IL e custo de gas).
- Critério de scoring de cada perfil é link visível abaixo dos cartões: "Como classificamos os pools?" — abre painel com metodologia.
Catálogo (sub-tab "Catálogo")
- Tabela de pares canônicos — entrada principal é o par (ex: "ETH/USDC"), não a instância (par × rede × fee). Sub-linhas expansíveis revelam instâncias por (rede, fee).
- Colunas (ordem da esquerda para direita, do mais decisor ao mais contextual):
  - Par (com badges de risco — ver Pilar 6 abaixo)
  - Atividade 24h (volume bruto, não razão — métrica do sort default)
  - Rendimento estimado (7d, sem IL) ⓘ
  - Vol/TVL (7d) ⓘ — métrica de eficiência (volume real ÷ capital travado, backward-looking)
  - TVL agregado cross-instância
  - Sinal — coluna dedicada a badges de risco (⚠ token não verificado, ⚠ Vol/TVL atípico, ⚠ APR extremo)
- Sort default: Atividade 24h desc (label visível: "Ordenado por atividade") — não TVL.
- Header da coluna ativa de sort é clicável e mostra a label do sort ativo. Sort por TVL fica a um clique.
Filtros (barra acima da tabela, altura equivalente entre todos)
- Buscar par — input sempre visível em desktop ≥ large breakpoint; em mobile, ícone que expande para input em bottom sheet.
- Rede — seletor com 3 seções ("Suas redes" com saldo / "Outras redes suportadas" / "Não suportadas") + contagem de pools por rede inline + busca dentro do dropdown.
- Mostrar apenas pools com tokens verificados em ambos os lados — toggle. Default desligado (neutralidade do catálogo mantida).
- Perfil de risco — seletor opcional ("Conservador / Moderado / Agressivo / Todos"). Quando selecionado, filtra catálogo com o mesmo critério dos cartões "Recomendados".
- Filtro de versão de AMM (V2/V3/Infinity/etc.) não aparece como filtro de primeiro nível — fica em "Mais filtros" para o avançado. Iniciante não escolhe versão de AMM, escolhe par.
Minhas posições (sub-tab)
- Lista de posições do usuário com par, valor atual, P&L estimado, IL realizado, e CTA "Gerenciar".
- Quando vazio com wallet conectada: empty state estruturado em jornada (ver estados abaixo).
- Quando sem wallet: empty state com CTA de conexão inline.

Cosmético (polish, vai depois do estrutural)

CTAs persistentes no topo direito da seção — "Criar pool" (secundário) e "Adicionar liquidez" (primário). Não competem com Hero.
Histórico — ícone discreto, abre painel com últimas posições fechadas + transações.

Regras de negócio

"Pares de liquidez" e "Stake de token único" são produtos com mecânica distinta — separados por segmento primário, nunca misturados na mesma tabela.
Sub-tab "Minhas posições" depende de carteira conectada — sem wallet, sub-tab continua acessível mas mostra empty state condicional, não skeleton indefinido.
Sort default é Atividade 24h desc, com label "Ordenado por atividade" visível ao lado do header da tabela. Clique no header de qualquer coluna troca o sort; sort selecionado persiste por sessão.
Filtros de status (Ativo/Inativo/Fechado) só aparecem dentro de "Minhas posições" e só quando o usuário tem ≥1 posição.
Filtro "Apenas pools verificados em ambos os lados" afeta apenas o catálogo — recomendados já vêm verificados por critério interno; minhas posições mostra tudo.
Badges de risco na coluna "Sinal":
- ⚠ amarelo: Vol/TVL > 3,0 (volume desproporcional — wash trading, MEV ou incentivo temporário)
- ⚠ amarelo: Rendimento estimado > 100% (yield triple-digit raramente sustentável)
- ⚠ vermelho: pelo menos um token não verificado (risco de rug pull, mint maligno)
- Thresholds são revelados em tooltip + página "Como classificamos os pools?" — critério explícito, não opaco.
Cartões "Recomendados" rotacionam por sessão, não por refresh — não viram banner promocional rotativo. Critério de seleção é estável e auditável.
Persistência de sub-tab por device (não por sessão): usuário que abriu "Minhas posições" da última vez volta direto nessa visão.

Estados não-triviais

Estado	Comportamento
Vazio — sem wallet conectada (sub-tab "Minhas posições")	"Conecte sua carteira para ver suas posições." + CTA "Conectar carteira" inline. Cartões "Recomendados" continuam acessíveis na sub-tab vizinha.
Vazio — wallet conectada, sem posições	Jornada estruturada com 3 caminhos hierarquizados: (1) "Ver pools recomendados para iniciantes" → vai para sub-tab Recomendados; (2) "Procurar um par específico" → foca o input de busca; (3) "Criar um novo pool" → secundário.
Vazio — rede errada selecionada	"Esta rede não tem pools suportados pela Kotai. Mude para uma rede compatível." + lista de redes sugeridas.
Loading — buscando posições	Skeleton com label ("Buscando suas posições em …") — nunca skeleton mudo.
Loading — catálogo carregando	Skeleton com label ("Carregando pools de …").
Erro — falha de RPC / subgraph	Banner não bloqueante no topo da tabela: "Dados desatualizados há X minutos. Tentando reconectar…" + CTA "Tentar agora". Tabela mostra última versão em cache com timestamp visível.
Parcial — multi-chain com uma rede falhando	Tabela mostra pools das redes que responderam + banner discreto: "Não foi possível carregar pools de . Outras redes continuam visíveis."
Saldo insuficiente para gas na rede da posição	Não bloqueia visualização; sinaliza no CTA "Gerenciar" da posição específica: "Sem saldo para taxa de rede".
Sucesso — usuário criou primeira posição	Após retorno do fluxo de criação, "Minhas posições" vira sub-tab default automaticamente e a nova posição entra destacada por 5s.

Microcopy crítico (PT-BR)

Elemento	Texto
Título hero	Ganhar rendimento
Sub-hero	Provea liquidez em pares de tokens e receba parte das taxas de cada troca feita no pool.
Link pedagógico	Como funciona o rendimento?
Segmento primário	Pares de liquidez \| Stake de token único
Sub-tabs	Recomendados \| Catálogo \| Minhas posições (3)
Cartão Conservador (justificativa)	Stablecoins têm IL próximo de zero. Bom ponto de partida para entender LP.
Cartão Moderado (justificativa)	Pares blue-chip + stable têm rendimento médio com IL administrável.
Cartão Agressivo (justificativa)	Pares voláteis podem ter IL maior que o rendimento se o preço se mover muito.
CTA do cartão	Ver detalhes
Link de metodologia	Como classificamos os pools?
Coluna rendimento	Rendimento estimado (7d, sem IL) ⓘ
Tooltip de rendimento	Cálculo baseado nas taxas observadas nos últimos 7 dias. Não inclui perda impermanente (IL) — o resultado real depende da variação de preço dos dois tokens.
Coluna eficiência	Vol/TVL (7d) ⓘ
Tooltip Vol/TVL	Volume real dividido pelo capital travado. Mostra o quanto o pool efetivamente trabalha. Diferente do rendimento estimado, esta métrica é observada, não projetada.
Coluna atividade	Atividade 24h
Label de sort ativo	Ordenado por atividade
Badge ⚠ Vol/TVL alto	Volume excepcionalmente alto pode indicar negociação artificial ou incentivo temporário. Verifique a trajetória antes de aportar.
Badge ⚠ APR extremo	Rendimentos acima de 100% raramente se sustentam. Veja a janela de cálculo antes de aportar.
Badge ⚠ Token não verificado	Pelo menos um dos tokens deste pool não passou nos critérios de verificação. Verificado não é recomendação de aporte.
Empty "Minhas posições" sem wallet	Conecte sua carteira para ver suas posições.
CTA inline	Conectar carteira
Empty "Minhas posições" wallet conectada	Você ainda não tem posições. Por onde quer começar?
Caminhos do empty	Ver pools recomendados para iniciantes \| Procurar um par específico \| Criar um novo pool
Loading com contexto	Buscando suas posições em …
Banner de dados desatualizados	Dados desatualizados há minutos. Tentando reconectar…
CTA de retry	Tentar agora

Rastreabilidade

🟢 Herdado

Tabs primárias por mecânica de produto acima da visão (catálogo vs. pessoal). Origem: [pancake-final § Fricção 1 — Léxico de protocolo] e [pancake/pools/pools-01.md § Fricção 1] — segmento de produto sempre acima do segmento de visão, hierarquia visual explícita.
Card de curadoria editorial atacando paradoxo da escolha em pools. Origem: [pancake/pools/pools-01.md § Insight] — "Escolhas Pancake" funciona como anti-paradoxo da escolha; Kotai herda e amplia (3 perfis em vez de 1 banner rotativo).
Vol/TVL como métrica observada lado a lado com APR projetado. Origem: [uniswap-final § Insight — Vol/TVL como verdade observada] e [uniswap/_consolidado/pools.md § Insight] — quando duas métricas competem, priorizar observada sobre projetada.
Empty state como jornada estruturada com 3 caminhos hierarquizados. Origem: [pancake-final § Insight — Cobertura proativa de estados não-triviais] e consolidado carteira-conectada — Kotai replica o padrão em "Minhas posições" vazio.
CTA descreve causa exata do bloqueio (em vez de bloqueio genérico). Origem: [pancake-final § Insight — Transparência proativa antes do CTA] — "Sem saldo para taxa de rede" em vez de botão cinza mudo.

🔴 Corrige

Fricção #1 do consolidado Pancake (Léxico de protocolo). "Pools" / "Farm" / "Syrup Pool" / "V2/V3/Infinity" como vocabulário primário substituídos por "Ganhar rendimento" (hero), "Pares de liquidez" / "Stake de token único" (segmento), versão de AMM rebaixada para "Mais filtros" do avançado. [pancake-final § Fricção 1]
Fricção #2 do consolidado Pancake (i18n parcial). Toda label, tooltip, badge e CTA escrita em PT-BR no momento da proposta. Formato numérico padronizado pelo locale. [pancake-final § Fricção 2]
Fricção estrutural Uniswap — Sort default por TVL prioriza estoque sobre atividade. Kotai inverte para Atividade 24h desc como sort default, com label visível. [uniswap/_consolidado/pools.md § Sort default por TVL]
Fricção estrutural Uniswap — Fragmentação de pares. Par canônico como entrada da tabela, instâncias por (rede, fee) como sub-linhas expansíveis. [uniswap/_consolidado/pools.md § Fragmentação de pares]
Fricção estrutural Uniswap — Outliers exibidos sem sinalização. Coluna "Sinal" com badges automáticos para Vol/TVL > 3,0 e rendimento > 100%, com tooltip pedagógico e threshold revelado. [uniswap/_consolidado/pools.md § Outliers sem sinalização]
Fricção estrutural Uniswap — Cauda longa sem fenestração de curadoria. Filtro "Apenas pools verificados em ambos os lados" + badge ⚠ vermelho em pool com pelo menos um token não verificado. [uniswap/_consolidado/pools.md § Cauda longa sem fenestração]
Fricção 2 Pancake pools-01 (skeleton ambíguo). Loading sempre com label de contexto ("Buscando suas posições em …"); empty state condicional substitui skeleton indefinido quando wallet desconectada. [pancake/pools/pools-01.md § Fricção 2]
Fricção 3 Pancake pools-01 (filtros de status em estado vazio). Filtros Ativo/Inativo/Fechado só aparecem dentro de "Minhas posições" e só quando há ≥1 posição. [pancake/pools/pools-01.md § Fricção 3]
Uniswap — Dropdown de rede sem busca e sem contagem de pools. Seletor de rede recebe busca integrada e contagem de pools por rede inline — corrige as duas fricções pontuais do consolidado Uniswap Pools (tela 3). [uniswap/_consolidado/pools.md § Ponto isolado tela 3 — fricção 2 e fricção 3]

🟡 Captura

Pilar 1 — Naming system. Hero, segmento e sub-tabs nomeados por verbo de intenção do usuário ("Ganhar rendimento", "Pares de liquidez", "Minhas posições"). Versão de AMM rebaixada para "Mais filtros". [pancake-final § Pilar 1]
Pilar 2 — CTA dinâmico + Default contextual. Sub-tab default "Recomendados" para iniciante; persistência por device pivota para "Minhas posições" no recorrente. Empty state com CTA inline contextual ("Conectar carteira"). [pancake-final § Pilar 2]
Pilar 4 — Educação contextual + Transparência financeira. Rendimento re-label como "Rendimento estimado (7d, sem IL) ⓘ" com tooltip pedagógico (oportunidade 🟡 do consolidado Uniswap pools). Coluna Vol/TVL ao lado, com tooltip explicando a diferença observado vs projetado. Link "Como classificamos os pools?" expõe metodologia. [pancake-final § Pilar 4] e [uniswap/_consolidado/pools.md § Sistema pedagógico de métricas DeFi]
Pilar 6 — Risk signaling sistêmico. Coluna "Sinal" dedicada a badges automáticos de risco (Vol/TVL atípico, APR extremo, token não verificado) — vetor que nenhum DEX expõe no nível de lista. [pancake-final § Pilar 6] e [uniswap/_consolidado/pools.md § Verificação por token em pool]
Pilar 7 — Curadoria opinionada. Pool finder por perfil (Conservador/Moderado/Agressivo) substitui banner rotativo "Escolhas Pancake" — curadoria assumida com critério explícito e metodologia auditável. [pancake-final § Pilar 7] e [pancake/pools/pools-01.md § Oportunidade]
Oportunidade — Par canônico cross-chain. Par como entidade primária da tabela, (rede, fee) como atributos expansíveis. Resolve fragmentação + semântica problemática de "Todas as redes" simultaneamente. [uniswap/_consolidado/pools.md § Par canônico cross-chain]
Oportunidade — Sort por atividade. Sort default "Atividade 24h desc" com label nomeado "Ordenado por atividade". [uniswap/_consolidado/pools.md § Sort por atividade]

⚪ Novo

Filtro "Perfil de risco" como filtro de primeiro nível no catálogo. Estende a curadoria dos cartões para a tabela completa, permitindo ao iniciante refinar o catálogo cru pelo mesmo critério dos cartões recomendados. Não aparece nos relatórios porque é extensão da curadoria opinionada para a tabela — vale o risco porque o iniciante que rejeita os cartões e vai para "Catálogo" hoje cai exatamente no problema que a curadoria evita; o filtro mantém a curadoria ativa nesse caminho. Evidência futura a coletar: telemetria de uso do filtro vs uso direto dos cartões; se uso for marginal, rebaixar para "Mais filtros".
Persistência da sub-tab por device (não por sessão). Resolve o conflito entre default pró-iniciante ("Recomendados") e velocity do recorrente ("Minhas posições") sem precisar de detecção heurística complexa. Risco: usuário em device compartilhado pega o estado do anterior — mitigável com reset no logout/disconnect.
Estrutura em 3 seções no seletor de rede ("Suas redes com saldo" / "Outras redes suportadas" / "Não suportadas"). Não aparece nos relatórios como padrão explícito de organização de seletor. Justificativa: o iniciante sem contexto de multi-chain reduz a decisão às redes onde já tem saldo sem esconder o universo completo — curadoria contextual sem ocultação. Risco: seção "Não suportadas" pode gerar confusão ("por que mostrar o que não funciona?") — mitigável com microcopy "Em breve" quando houver plano de expansão. Evidência futura: taxa de clique por seção e abandono do seletor vs conversão por rede.

Trade-offs e segunda ordem

Pool finder por perfil exige metodologia transparente de scoring. Classificar errado destrói confiança; demanda manutenção contínua, indexação de histórico de IL realizado por par, e governança editorial do critério. Custo recorrente real. Mitigação: começar com 3 perfis usando heurísticas simples e auditáveis (volatilidade dos tokens + estabilidade do par + janela de Vol/TVL ≥ 30d), evoluir para scoring mais sofisticado com telemetria.
Par canônico cross-chain exige canonical mapping de token (USDC nativo vs bridged, WETH vs ETH). Risco semântico se mapeamento for incorreto: misturar bridged-USDC com nativo-USDC cria confusão pior que a fragmentação atual. Decisão arquitetural com custo de manutenção alto; vai além desta tela e precisa de definição estrutural antes da implementação.
Coluna "Sinal" com badges automáticos infla a linha da tabela (mais um elemento visual por linha). Mitigação: ícone único e compacto + tooltip; em mobile, badge único combinado quando houver múltiplos sinais.
Sort por atividade em vez de TVL vai ouvir crítica de power user ("vocês escondem o maior pool da rede"). Aceitar — o sort por TVL fica a um clique e o label nomeado ("Ordenado por atividade") torna a decisão de produto explícita.
Filtros de versão de AMM rebaixados para "Mais filtros" podem irritar avançado V3/V4 que usa o filtro como atalho. Mitigação: "Mais filtros" persiste expandido por device para quem já usou, virando atalho de retorno.
Sub-tab persistente por device exige storage local; em modo anônimo / privado o default sempre cai em "Recomendados" — comportamento aceitável e consistente.
Empty state com 3 caminhos infla número de strings de UI e exige i18n correta de cada caminho — endereçado pelo princípio de microcopy PT-BR como parte da proposta.
Banner de dados desatualizados exige infraestrutura de timestamp confiável por dado mostrado — sem isso, o banner vira ruído. Custo de observabilidade real.

Conflitos de pilar resolvidos

Pilar 2 (default contextual: recorrente vê "Minhas posições") vs Pilar 7 (curadoria opinionada: iniciante deve ver "Recomendados"). Resolvido por hierarquia: default em primeira visita = "Recomendados" (Pilar 7 vence porque o target prioritário é iniciante); persistência por device pivota para "Minhas posições" só depois que o usuário demonstrou ser recorrente — Pilar 2 entra como camada subsequente, não como default.
Pilar 6 (risk signaling) vs neutralidade do catálogo cru. Resolvido mantendo default "mostrar tudo" no catálogo (neutralidade preservada) e adicionando badges automáticos + filtro opcional "Apenas verificados" — sinaliza sem editorializar a lista.

Visualizar Pool — Tela 01: Entrada do pool detail (estado base, sem ação ativa)

1. Função da tela

Permitir que o usuário iniciante/intermediário avalie a saúde de um pool específico em até 10 segundos e decida com segurança se quer operar (trocar tokens ou adicionar liquidez), sem precisar de contexto externo — foco explícito em iniciante mobile BR/LatAm.

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

A. Cabeçalho de identidade do pool — sticky durante todo o scroll

Breadcrumb: Ganhar rendimento › USDC/ETH
Par de tokens: avatares + USDC / ETH
Label de orientação ativa: Mostrando USDC/ETH ↕ — o ↕ é a setinha de inversão; o prefixo "Mostrando" deixa explícito que há uma orientação controlada pelo usuário, não que ele navegou para outro pool. Breadcrumb sempre mantém ordem canônica (maior liquidez primeiro) independentemente da inversão ativa.
Badge de versão: v3 · Tarifa 0,05% (nome técnico Uniswap V3 apenas em tooltip ou secondary label)
Endereço compacto: 0x8ad5...6b4e [copiar] [ver no explorador]

B. KPI chip-strip de saúde — imediatamente abaixo do cabeçalho, antes do chart

Três chips inline num único carrossel horizontal:

APR 15,8%
TVL R$135M
Vol ↑12%

Coloração contextual por threshold: verde (ativo), âmbar (baixa atividade), strip inteiro âmbar + badge ⚠ Pool com pouca atividade · Slippage pode ser maior quando Vol 24h < 0,1% do TVL.

Tap em qualquer chip → bottom sheet com dado completo (mini-chart 7d) + caption narrativa contextual gerada por regras.

Este strip é o substituto da sidebar de saúde desktop que sumia do viewport mobile nos concorrentes — resolve a fricção de APR/TVL/Volume fora do fold antes do CTA de liquidez.

C. Chart de atividade — área central

Default: tab Volume (não Preço) — usuário na pool detail avalia saúde de infraestrutura, não trajetória do ativo
Toggle de tipo acima do chart: Volume | Liquidez | TVL como chips
Presets de tempo: 1D | 1S | 1M | 1A
Interação: tap-and-stick em mobile (nunca hover-only)
Headline de narrativa abaixo do chart, computada client-side: "Atividade concentrada em 1 transação às 06h — 67% do volume"
Em pool sem atividade: área cinza + headline: "Sem atividade registrada nos últimos 7 dias"

D. Sticky CTA bar inferior — independente do scroll, sempre acessível

Mobile: dois botões empilhados em coluna, full-width cada (Fazer swap / Adicionar liquidez)
Desktop: sidebar direita com os dois CTAs side-by-side
Nunca trunca texto — PT-BR verificado em todos os breakpoints antes de qualquer release

Cosméticos (podem ser adicionados após o paradigma estar estável)

Timestamp de snapshot: Dados às 14:28 · atualiza a cada 30s — rodapé discreto; todos os KPIs da tela derivam do mesmo snapshot, eliminando divergência intra-tela
Link âncora: Ver estatísticas detalhadas ↓ — scroll suave para Tela 02

3. Regras de negócio

O par, a rede e a versão são herdados da URL/contexto de navegação — nenhum campo começa vazio ao chegar nesta tela.
A orientação de par persiste durante a sessão mas reverte à ordem canônica ao recarregar. O breadcrumb sempre exibe a ordem canônica, independentemente da inversão ativa.
Badge ⚠ Pool com pouca atividade dispara quando Vol 24h / TVL < 0,001 (0,1%). O threshold é exposto como critério clicável — não é uma black-box editorial.
APR = 0,00% é exibido em âmbar no chip, nunca em vermelho (não é erro — é dado real). Não exibe número em fonte gigante sem caption.
A headline de narrativa do chart é computada dos dados já carregados (N transações, % do volume em 1 transação, tipo dominante). Não é chamada extra de API.
Chart inicia no tab Volume porque esse é o sinal de saúde primário para LP — Preço é relevante para trader mas não para quem avalia se vale depositar liquidez.
Todos os dados do chip-strip, chart e headline derivam do mesmo snapshot do timestamp visível — coerência intra-tela garantida arquiteturalmente.
A tela carrega e exibe cotações mesmo sem carteira conectada (try-before-connect) — CTAs ficam ativos e ao tocar abrem o drawer de conexão sem perder contexto da pool.
Ao retornar do widget de swap (Tela 03) após transação concluída, a tela exibe toast de confirmação por 5 segundos.

4. Estados não-triviais

Vazio (pool sem dados históricos) Chart: área cinza com "Sem atividade registrada nos últimos 30 dias". KPI chips: -- no lugar do número. Headline de narrativa: "Este pool não teve atividade recente registrada." CTA bar permanece ativa (swap pode ser tentado mesmo em pool sem histórico — não bloquear).

Loading (entrada inicial) Skeletons: chip-strip (3 pills skeleton), área do chart (retângulo gradiente), sticky CTA bar já renderizada (os botões existem antes dos dados). Breadcrumb de identidade carrega antes dos dados numéricos — usuário sabe em qual pool está mesmo durante o carregamento.

Erro de RPC / subgraph Chart exibe área cinza + tooltip Dados temporariamente indisponíveis (não some silenciosamente). Chips exibem ? com tooltip Erro ao carregar · toque para tentar novamente. Timestamp muda para Última atualização: 14:28 (há 3 min) em cor âmbar.

Rede errada / Wallet em rede diferente da pool Banner contextual abaixo do cabeçalho (não bloqueia a tela): Sua carteira está em Ethereum · Esta pool é BNB Chain · Trocar rede para operar. CTA bar fica visível; ao tocar, abre modal de troca de rede — não o swap direto.

Carteira desconectada Tela carrega normalmente. CTAs ativos. Ao tocar em qualquer CTA, abre o drawer de conexão preservando o contexto da pool (par e versão não são perdidos).

Pool deslistada / arquivada Banner no topo: Esta pool está inativa e não aceita novos aportes · Ver pools similares. CTA Fazer swap continua habilitado (swap em pool V2/V3 legada ainda funciona). CTA Adicionar liquidez fica desabilitado com label Aportes encerrados.

Sucesso (retorno do widget após swap) Toast no rodapé da tela: Swap enviado · ver transação por 5 segundos. Chip-strip atualiza com os dados mais recentes ao retornar.

5. Microcopy crítico (PT-BR)

Elemento	Texto
Breadcrumb	`Ganhar rendimento › USDC/ETH`
Label de orientação	`Mostrando USDC/ETH ↕`
Badge de versão	`v3 · Tarifa 0,05%`
Badge pool inativa	`⚠ Pool com pouca atividade · Slippage pode ser maior`
Headline narrativa (pool ativa)	"Atividade estável: 127 operações ontem, maioria entre 09h–14h."
Headline narrativa (pool morta)	"Volume baixo nos últimos 7 dias. Operações neste pool podem ter slippage elevado."
Headline narrativa (pico isolado)	"Atividade concentrada em 1 transação às 06h — 67% do volume."
Tooltip threshold de atividade	`Pool com pouca atividade: volume < 0,1% do TVL nas últimas 24h. Isso pode aumentar o slippage das suas operações.`
CTA primário	`Fazer swap`
CTA secundário	`Adicionar liquidez`
CTA desabilitado (pool arquivada)	`Aportes encerrados`
Banner rede errada	`Sua carteira está em [rede A] · Esta pool é [rede B]`
CTA banner rede errada	`Trocar rede para operar`
Banner pool arquivada	`Esta pool está inativa e não aceita novos aportes`
CTA banner pool arquivada	`Ver pools similares`
Erro de dados	`Dados temporariamente indisponíveis`
Timestamp	`Dados às 14:28 · atualiza a cada 30s`
Link âncora	`Ver estatísticas detalhadas ↓`
Toast sucesso (retorno)	`Swap enviado · ver transação`

6. Rastreabilidade obrigatória

🟢 Herdado

Chart default = Volume (não Preço) em pool detail — [uniswap visualizar-pool.md § Insight: Contexto herdado na ação]. Usuário em pool detail pensa em saúde de infraestrutura, não em trajetória do ativo. Replicação consciente.
Breadcrumb Pools › PAR em mobile — [uniswap visualizar-pool.md § Insight: Sticky de identidade + CTAs em mobile]. Identidade da pool nunca desaparece durante o scroll.
CTAs primários em sticky bar inferior mobile — [uniswap visualizar-pool.md § Insight: Sticky de identidade + CTAs em mobile]. Acesso à ação não depende de scroll-up.
Try-before-connect — tela carrega sem wallet — [uniswap-final § Ação imediata sem commit nem onboarding]. Usuário não é bloqueado antes de avaliar o produto.
Presets de tempo no chart (1D / 1S / 1M / 1A) — convenção válida de mercado presente em Uniswap e PancakeSwap nas análises de pool. Extensão do princípio de chips de preset estabelecido em [uniswap visualizar-pool.md § Presets chips em qualquer decisão financeira] (chips como padrão de âncora rápida para decisões numéricas); aplicado aqui ao eixo temporal do chart. Replicação consciente.
Tap-and-stick em gráficos (nunca hover-only) — [pancake-final § Pilar 5 — Mobile-first interaction]. Mobile não tem hover; interação de gráfico precisa funcionar por toque.

🔴 Corrige

KPI chip-strip de saúde antes do chart em mobile — corrige [uniswap visualizar-pool.md § Fricção estrutural: Paridade informacional desktop↔mobile quebrada]. APR/TVL/Volume sumiam do fold mobile antes do CTA de liquidez; o chip-strip garante que nenhuma decisão de execução acontece sem os três sinais de saúde visíveis.
Orientação de par com label "Mostrando USDC/ETH ↕" — corrige [uniswap visualizar-pool.md § Fricção estrutural: Inversão de par sem âncora canônica]. A setinha de inversão existia mas a mudança de ordem visual era interpretada como navegação para outro pool pelo iniciante.
Headline de narrativa abaixo do chart — corrige [uniswap visualizar-pool.md § Fricção estrutural: APR 0,00% mudo em fonte gigante] (conexão indireta) e [uniswap-final § Fricção 6 — Métricas DeFi sem decomposição]. Dado cru sem narrativa não instrui o iniciante.
CTAs sticky em coluna full-width (sem truncamento) — corrige [uniswap visualizar-pool.md § Fricção estrutural: Truncamentos PT-BR sistêmicos]. + Adicionar liqu… truncado na sticky bar é o caso mais crítico identificado.
Timestamp único por snapshot (coerência intra-tela) — corrige [uniswap visualizar-pool.md § Fricção estrutural: Métricas vivas sem âncora de snapshot]. Sem timestamp, KPIs divergem entre capturas e usuário atribui inconsistência ao produto.

🟡 Captura

KPI chip-strip com tap-to-expand contextual — captura [uniswap visualizar-pool.md § Oportunidade 1: Contexto persistente no ato de operar]. Padrão atual da indústria: todos os concorrentes perdem os KPIs de saúde quando o widget de ação abre. O chip-strip é o ponto de entrada para o drawer narrativo e o precursor do strip que vai aparecer no bottom sheet da Tela 03. Hipótese: nenhum DEX principal oferece "sinal de saúde sempre visível + tap-to-explain" antes de qualquer decisão de execução.
Headline de narrativa automática do chart — captura [uniswap visualizar-pool.md § Oportunidade 3: Narrativa automática dos dados]. Todos os concorrentes deixam chart sem headline — dado existe, narrativa não. Uma frase muda o tipo de pergunta que o iniciante faz antes de agir.
Badge ⚠ Pool com pouca atividade com threshold exposto — captura [uniswap visualizar-pool.md § Oportunidade 2: Pré-visualização rica do swap + sinalização de pool inativa]. Todos os concorrentes: widget vazio visualmente idêntico em pool ativa ou morta.

⚪ Novo

Threshold de atividade exposto como critério clicável (Vol 24h / TVL < 0,001): a porcentagem exata de threshold não tem origem direta nos relatórios — é decisão de produto nova. Justificativa: o risco de threshold mal calibrado (falso positivo assusta usuário; falso negativo deixa pool morta sem aviso) só pode ser mitigado com critério público e ajustável. Evidência a coletar: testes A/B com 3–5 valores de threshold em período de 30 dias, medindo abandono na CTA vs reclamação de slippage inesperado.

7. Trade-offs e segunda ordem

Cognitive load: o chip-strip adiciona ~36 px acima do chart. Risco de parecer excessivo em pool saudável onde os três números são positivos. Mitigação: coloração verde discreta em pool ativa (o strip desaparece visualmente no positivo; aparece em âmbar quando importa).

Implementação da headline narrativa: requer 4–5 templates conservadores bem definidos e regras de classificação por bucket. Uma caption gerada com dado stale ou com bucket errado é pior que silêncio — exige QA específico de narrativa por tipo de pool (pool nova, pool morta, pool com pico isolado, pool estável).

i18n: cada template de headline precisa de tradução e auditoria de breakpoint em PT-BR — não é só string estática. Processo de release precisa incluir checklist "todas as headlines foram testadas em PT-BR em todos os breakpoints".

Snapshot architecture: garantir coerência intra-tela via snapshot único é decisão arquitetural backend — requer um endpoint de "pool snapshot" que retorna todos os KPIs atomicamente, não chamadas individuais por métrica. Custo de implementação médio; ganho: elimina a classe de bugs de "TVL e Volume divergem porque vieram de chamadas com 3s de diferença".

Threshold de atividade: qualquer threshold fixo será criticado por LPs de pools legítimas de nicho. A exposição do critério (clicável) é a mitigação editorial — não elimina o problema mas dá ao usuário a ferramenta para discordar conscientemente.

Visualizar Pool — Tela 02: Estatísticas, Composição e Histórico de Transações

1. Função da tela

Permitir que o usuário iniciante/intermediário entenda em profundidade a saúde financeira do pool — APR contextualizado com narrativa, composição visual de saldos, histórico de transações on-chain auditável — tudo sem sair do produto para um explorador externo; foco explícito em iniciante que precisa de mediação para interpretar métricas DeFi.

2. Componentes / elementos

Estruturais (definem o paradigma da seção)

A. Card de APR narrativo — elemento de maior peso visual; define o paradigma de pedagogia inline da tela

Valor em fonte grande: ex. 15,84%
Decomposição inline imediatamente abaixo do número (não em tooltip separado): Taxas orgânicas: 15,84% · Incentivos: — · Faixa 7d: 14–19%
Caption narrativa contextual: gerada por bucket de situação, não label estático. Exemplos:
- Pool ativa: "Calculado sobre as taxas coletadas nos últimos 30 dias. Volume estável neste período."
- APR 0%: "Volume baixo nas últimas 24h. Taxas insuficientes para gerar rendimento anual perceptível."
- Com incentivos temporários: "Inclui R$X/dia em incentivos válidos até DD/MM. Sem incentivos, APR seria Z%."
Tap → drawer com mini-chart de APR 7d + CTA Como o APR é calculado ›

O card de APR nunca exibe apenas o número em fonte gigante sem a decomposição e caption. O número grita; a narrativa contextualiza.

B. Cards de métricas secundárias (TVL, Volume 24h, Taxas coletadas 24h)

Cada card: label primário em PT-BR (verbo de benefício) + valor + delta colorido + tap-to-expand
- Capital total depositado (secondary: TVL) — R$135M + ↑1,27%
- Operações em 24h (secondary: Volume 24h) — R$2,4M + ▼81,84%
- Taxas coletadas em 24h (secondary: Fees 24h) — R$12,60 + ↓93%
Todos os valores em R$ como nominal, USD como eyebrow discreto: ≈ US$27M
Tap → bottom sheet com mini-chart 7d + caption narrativa do mesmo tipo do card APR
Nenhum delta percentual isolado sem contexto qualitativo inline (ex: ▼81,84% em âmbar com tooltip Queda acentuada em relação à média de 7 dias)

C. Barra de composição de saldos — mobile-first; substitui o dado de saldo que era descartado em mobile nos concorrentes

Barra horizontal full-width dividida proporcionalmente entre os dois tokens
Labels percentuais inline na própria barra: 52% USDC | 48% ETH
Abaixo da barra: valores absolutos por token com eyebrow USD
- R$12,4M USDC (≈ US$2,5M)
- R$11,5M ETH (≈ US$2,3M)
Em desequilíbrio extremo (>80/20): barra em coloração âmbar + badge ⚠ Pool desbalanceada · pode afetar slippage
Tap na barra → drawer explicando o que composição desequilibrada significa na prática

D. Tabela de transações on-chain — dados auditáveis sem sair do produto

Colunas mobile: Tipo | Valor (R$) | Quando

Coluna Tipo: ícone seta ↑ verde (compra) / ↓ vermelho (venda) — sem texto de símbolo truncado (substitui coluna "Vender WIS…" / "Comprar W…" dos concorrentes que truncava o símbolo)
Chevron › discreto na borda direita de cada linha → row-expand via bottom sheet 60%
Card de row-expand: horário completo, tipo, valor R$, quantidade token A, quantidade token B, carteira com badge via roteador (se contrato em base canônica da Kotai), link Ver no explorador →
Badge via roteador limitado a contratos verificados (1inch Universal Router, 0x Protocol, Uniswap Universal Router) — não faz inferência "bot vs humano"; só rotula fato verificável
Subtitle de contexto acima da tabela: 143 transações em 24h · 89 vendas, 54 compras · 63% do volume em 3 operações
Paginação: 1–20 de 143 · Carregar mais — ao carregar mais, snapshot da primeira página não muda (coerência com timestamp da sessão)
Padding de rodapé igual à altura da sticky CTA bar: última linha não fica oculta

E. Seção de contratos on-chain (Links)

Eyebrow semântico acima de cada entrada em uppercase extra-small: POOL / TOKEN
Nome completo do contrato (nunca truncado): USDC — Circle USD Coin nativo
Endereço compacto + [copiar] + [ver no explorador]
Badge de verificação: ✓ Verificado pela Kotai ou Não verificado — com tooltip de critério exposto
A distinção pool/token via eyebrow resolve a ambiguidade de "qual contrato é o pool e quais são os tokens" sem precisar de label longa que truncaria em mobile

Cosméticos (estáveis após paradigma estabelecido)

Timestamp compartilhado com Tela 01 — Dados às 14:28 · atualiza a cada 30s — rodapé discreto
Header de seção: Desempenho do pool (não "Statistics" em inglês, não "Estatísticas" como label técnico)

3. Regras de negócio

APR nunca aparece sem decomposição e caption narrativa. Caption gerada por bucket (máximo 5 templates conservadores); template incorreto em caso extremo é pior que silêncio — preferir caption genérica honesta a caption específica errada.
Em erro de dados para APR: card exibe -- com badge Dados indisponíveis · atualiza em 30s; caption de narrativa não é exibida em estado de erro (evitar narrativa gerada com dado stale).
Todos os valores monetários: R$ como nominal, USD como eyebrow ≈ US$X. Nunca misturar formato (sem $3,38K — Fricção 2 do consolidado Pancake). Abreviação de magnitude: R$135M, R$2,4M, R$12,60 — sem K misturado com vírgula decimal PT-BR.
Barra de composição não renderizada em pools com mais de 2 tokens (caso raro em V2/V3, mas existente em outros AMMs). Exibir aviso Composição de múltiplos tokens com link para o explorador.
Tabela de transações herda os dados do snapshot da sessão para as primeiras 20 linhas. "Carregar mais" busca dados mais recentes, mas não altera o snapshot das linhas já carregadas — evita que linhas "desapareçam" ao paginar.
Badge via roteador só aparece para endereços em base canônica mantida pela Kotai. A base deve ser versionada e auditável — é dado fático, não inferência.
Seção de contratos: eyebrow POOL para o contrato do pool; eyebrow TOKEN para cada token do par. Em pool com mais de 2 tokens: todos recebem eyebrow TOKEN.
Critério de ✓ Verificado pela Kotai exposto em tooltip: liquidez mínima [threshold], contrato auditado, sem nome similar a token canônico conhecido. O critério é estático por versão de release — não muda silenciosamente.
O timestamp desta tela é o mesmo da Tela 01 (mesma sessão de carregamento). Se o usuário navega para outra tela e volta, um novo snapshot é gerado com novo timestamp.

4. Estados não-triviais

Loading Skeletons do card APR (número + linhas de decomposição + caption), cards de métricas (3 pills), barra de composição (gradiente cinza), tabela (8 linhas skeleton), seção de contratos (2 entradas skeleton).

Erro de dados para APR Card APR: -- + badge âmbar Dados indisponíveis · atualiza em 30s. Caption narrativa não exibida. Cards de métricas secundárias tentam carregar independentemente (falha parcial não colapsa a seção inteira).

Pool sem transações (vazio) Tabela: empty state Nenhuma transação encontrada nas últimas 24h. Subtitle de contexto some. Barra de composição e cards de métricas podem ainda exibir dados históricos (TVL, composição persistem mesmo sem atividade recente).

Dados parciais (ex: TVL disponível, Volume não) Cards com dado disponível exibem normalmente. Cards sem dado exibem Indisponível sem colapsar o layout da seção — evitar "zero" falso no lugar de "dado ausente".

Desequilíbrio extremo de composição (>80/20) Barra com coloração âmbar (lado menor em âmbar). Badge: ⚠ Pool desbalanceada · pode afetar slippage. Tap → drawer: "Quando um pool tem muito mais de um token que do outro, a relação de preço se afasta do mercado geral. Operações grandes podem ter slippage elevado."

Contrato não verificado Eyebrow mantido (TOKEN ou POOL). Badge Não verificado em cor neutro-âmbar. Tooltip: Este contrato ainda não foi verificado pelos critérios da Kotai. Use com cautela. Não bloqueia a visualização — sinaliza, não censura.

Scroll além da sticky CTA bar (mobile) Padding invisível de rodapé igual à altura da sticky bar: última linha da tabela sempre visível acima dos CTAs. Estado cosmético-estrutural sem implementação difícil, mas crítico para não ocultar dados.

5. Microcopy crítico (PT-BR)

Elemento	Texto
Header de seção	`Desempenho do pool`
Card APR: caption pool ativa	"Calculado sobre as taxas coletadas nos últimos 30 dias. Volume estável neste período."
Card APR: caption APR 0%	"Volume baixo nas últimas 24h. Taxas insuficientes para gerar rendimento anual perceptível."
Card APR: caption com incentivos	"Inclui R$X/dia em incentivos válidos até DD/MM. Sem incentivos, APR seria Z%."
Card APR: CTA drawer	`Como o APR é calculado ›`
Card APR: dado indisponível	`Dados indisponíveis · atualiza em 30s`
Card TVL: label primário	`Capital total depositado`
Card TVL: label secondary	`TVL`
Card Volume: label primário	`Operações em 24h`
Card Volume: label secondary	`Volume 24h`
Card Taxas: label primário	`Taxas coletadas em 24h`
Card Taxas: label secondary	`Fees 24h`
Barra de composição: header	`Composição atual do pool`
Badge desequilíbrio	`⚠ Pool desbalanceada · pode afetar slippage`
Drawer desequilíbrio	"Quando um pool tem muito mais de um token que do outro, a relação de preço se afasta do mercado geral. Operações grandes podem ter slippage elevado."
Tabela: subtitle	`143 transações em 24h · 89 vendas, 54 compras · 63% do volume em 3 operações`
Tabela: empty state	`Nenhuma transação encontrada nas últimas 24h`
Tabela: paginação	`1–20 de 143 transações · Carregar mais`
Row-expand: header	`Detalhes da transação`
Row-expand: campo carteira (roteador)	`Via 1inch · 0xe16A...B4cF`
Row-expand: link externo	`Ver no explorador →`
Seção contratos: header	`Contratos on-chain`
Eyebrow pool	`POOL`
Eyebrow token	`TOKEN`
Badge verificado	`✓ Verificado pela Kotai`
Badge não verificado	`Não verificado`
Tooltip verificação	`Critério: liquidez mínima [threshold], contrato auditado, sem nome similar a token canônico conhecido`
Tooltip não verificado	`Este contrato ainda não foi verificado pelos critérios da Kotai. Use com cautela.`
Timestamp	`Dados às 14:28 · atualiza a cada 30s`

6. Rastreabilidade obrigatória

🟢 Herdado

Dados on-chain inline sem desvio para explorador externo — [uniswap visualizar-pool.md § Insight: Dados on-chain inline]. A tabela de transações completa pertence dentro da entidade, não atrás de link externo. Trust signal por exposição direta.
Princípio de progressive disclosure nos cards de métricas — [uniswap-final § Progressive disclosure como padrão arquitetural]. Feature complexa não precisa de tab dedicada — precisa de camada de disclosure sob demanda. O Uniswap aplica esse princípio com consistência em múltiplos fluxos (stepper, tabs, fee tier expansível). Nota: a implementação específica de "tap → mini-chart 7d + caption narrativa" NÃO é padrão herdado — é 🟡 Diferenciador capturado em Oportunidade 3 do consolidado (já registrado abaixo).
Equivalente USD ao lado de todo token amount — [uniswap-final § Múltiplas representações do mesmo dado + bidirecionalidade]. Número cru sem contexto de valor fiat é fricção de leitura para iniciante BR.
Presets de range de tempo (1D / 1S / 1M) no chart do drawer de métricas — [uniswap visualizar-pool.md § Presets chips em qualquer decisão financeira]. Convenção válida de mercado.

🔴 Corrige

Card APR com decomposição + caption narrativa — corrige [uniswap visualizar-pool.md § Fricção estrutural: APR 0,00% mudo em fonte gigante]. APR 0% em fonte gigante sem mediação: iniciante fecha a página com conclusão errada. A caption contextualiza a causa sem precisar de tooltip que o iniciante ignoraria.
Barra de composição full-width em mobile — corrige [uniswap visualizar-pool.md § Fricção estrutural: Paridade informacional desktop↔mobile quebrada]. A barra de saldos proporcionais era descartada em mobile e substituída por dois pares número+token sem relação visual entre eles — iniciante mobile perdia o sinal mais pedagógico do card.
Subtitle de narrativa acima da tabela de transações — corrige [uniswap visualizar-pool.md § Fricção estrutural: APR 0,00% mudo] (conexão com a classe de fricção "dado sem narrativa") e [uniswap-final § Fricção 6 — Métricas DeFi sem decomposição, janela ou comparativo].
Coluna Tipo com ícone (↑↓) em vez de texto truncado — corrige [uniswap visualizar-pool.md § Fricção cosmético-estrutural: Coluna Tipo truncada na tabela]. "Vender WIS…" e "Comprar W…" são truncamentos garantidos por construção; ícone semântico com cor elimina o problema estruturalmente.
Labels de cards em verbo de benefício (PT-BR) — corrige [pancake-final § Fricção 1 — Léxico de protocolo como vocabulário primário] e [pancake-final § Fricção 2 — i18n parcial]. "TVL", "Fees 24h" como labels primárias são léxico de protocolo, não linguagem do usuário.
Eyebrow semântico POOL/TOKEN na seção de contratos — corrige [uniswap visualizar-pool.md § Fricção estrutural: Truncamentos PT-BR sistêmicos na section Links]. Labels P…, Wise…, Wrapp… truncados a 3–5 caracteres — eyebrow de 4–5 caracteres em uppercase entrega contexto sem precisar de nome longo.
Badge via roteador no row-expand — corrige (classe de) [uniswap visualizar-pool.md § Fricção estrutural: Desacoplamento de contexto]. Sem rotulagem, histórico de transações parece "1 bot fazendo 7 dos 9 swaps" quando na verdade são usuários diferentes via agregador.
Padding de rodapé para sticky bar — corrige [uniswap visualizar-pool.md § Fricção cosmética: sticky bar sem padding de scroll]. Última linha da tabela oculta atrás da sticky bar. Correção trivial com impacto direto na usabilidade.

🟡 Captura

Narrativa automática do chart e das métricas — captura [uniswap visualizar-pool.md § Oportunidade 3: Narrativa automática dos dados em 3 níveis]. Todos os concorrentes deixam chart, transações e KPIs sem narrativa. A diferenciação é: uma frase de contexto muda o tipo de pergunta que o iniciante faz antes de agir. Hipótese: usuário iniciante que lê "Volume baixo nas últimas 24h" antes de tocar em Adicionar liquidez tem taxa de abandono de "má decisão" menor que usuário que viu apenas APR 0,00% em fonte grande.
Rotulagem semântica POOL/TOKEN + badge via roteador — captura [uniswap visualizar-pool.md § Oportunidade 5: Rotulagem semântica em listas on-chain]. Todos os concorrentes listam contratos sem eyebrow de tipo e histórico de transações sem distinção de roteadores. Hipótese: "Via 1inch" lido em 1 segundo muda o modelo mental sobre atividade do pool.
Row-expand com card detalhado de transação — captura [uniswap visualizar-pool.md § Oportunidade 6: Tabela mobile expansível por linha]. Todos os concorrentes descartam colunas em mobile sem affordance de recuperação. Hipótese: paridade informacional completa com desktop, sem sair do produto — intermediário que audita trades deixa de migrar para Etherscan para tarefas básicas.
Caption narrativa gerada por regras — captura [pancake-final § Pilar 4 — Educação contextual sistêmica + transparência financeira ativa]. "Padrão de tooltip de 3 camadas: sintoma + causa + custo concreto" aplicado ao card APR. Diferenciação: Kotai como "DEX que ensina enquanto mostra dados".

⚪ Novo

Máximo de 5 templates conservadores de caption por tipo de dado: a limitação intencional a 5 templates não tem origem direta nos relatórios — é decisão de processo de produto. Justificativa: caption errada (bucket errado → diagnóstico errado) é pior que silêncio; o teto de 5 templates força conservadorismo editorial. Evidência a coletar: A/B test de "caption vs sem caption" medindo tempo de permanência na seção de Estatísticas e taxa de conversão para CTA de liquidez.
Badge ⚠ Pool desbalanceada com threshold 80/20: o threshold específico não tem origem nos relatórios. Justificativa: 80/20 é o limiar convencional onde slippage começa a ser perceptível em AMMs de produto constante (XY=K). Evidência a validar: testar com 70/30 e 85/15 medindo reclamações de slippage inesperado em pools com desequilíbrio próximo ao threshold.

7. Trade-offs e segunda ordem

Custo de copywriting de captions narrativas: 5 templates × número de idiomas × revisão por release. A caption precisa ser assinada por alguém que entende DeFi e escreve em PT-BR para iniciante — não pode ser tradução automática de EN. Processo: designer de conteúdo valida cada template com 3 usuários representativos antes de entrar em produção.

Risco de caption com dado stale: se o snapshot de APR for antigo (>5 min), a caption pode descrever uma situação que não é mais a realidade. Mitigação: em estado de dado stale, exibir -- no número e omitir a caption — nunca exibir narrativa sobre dado não confiável.

Complexidade da base canônica de roteadores: a base precisa ser mantida por release, versionada e pública (para transparência do critério de via roteador). Se não for mantida, o badge passa a ser misleading ao longo do tempo. Custo de manutenção: 1h/mês de revisão + CI que valida endereços conhecidos.

Row-expand vs coluna extra em desktop: em desktop, onde o viewport permite 6+ colunas, o chevron de row-expand é redundante com dados já visíveis. Proposta: row-expand ativo apenas em mobile; desktop exibe colunas completas sem chevron. Evita adicionar interação desnecessária onde o dado já está acessível de um olhar.

i18n: cada caption narrativa, cada label de card e cada eyebrow semântico são strings em PT-BR que precisam de i18n se o produto expandir para outros idiomas. A estrutura "label primário verbo de benefício + secondary label técnico" duplica o número de strings por elemento, mas permite que usuários avançados filtrem pelo label técnico se quiserem. Custo aceito: é o trade-off de servir target iniciante com naming adequado.

Visualizar Pool — Tela 03: Swap Contextualizado (Bottom Sheet Ativado)

1. Função da tela

Permitir que o usuário execute um swap diretamente do contexto do pool, com os sinais de saúde da pool preservados e visíveis durante todo o preenchimento — eliminando o risco de operar em pool inativa sem perceber e garantindo que nenhuma decisão de execução acontece sem contexto; foco explícito em iniciante mobile que depende dos sinais do produto para filtrar pools inadequadas.

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

A. Grab handle + mini-chip de identidade — persistente, nunca removido

Grab handle padrão de bottom sheet
1 linha abaixo do grab handle, sempre visível mesmo em full-screen: USDC/ETH · v3 · Tarifa 0,05%
Propósito: quando o sheet expande para full-screen e a Tela 01 desaparece atrás do overlay, o usuário ainda sabe em qual pool está operando — elimina o risco de operar no par errado (v2 vs v3, fee 0,3% vs 0,05%)

B. Strip de saúde contextual — imediatamente abaixo do mini-chip, antes de qualquer campo de input

3 valores em linha: APR 15,8% · TVL R$135M · Vol ↑12%
Mesma coloração e dados do chip-strip da Tela 01 (mesmo snapshot) — não é uma segunda fonte de dados
Em pool com pouca atividade: strip inteiro em âmbar + ⚠ Pool com pouca atividade · Slippage pode ser maior
Tap no strip → fecha o sheet suavemente e ancora na seção de Estatísticas da Tela 02 (não perde contexto de qual pool)
Esses dois componentes (mini-chip + strip) somam ~60 px no topo do sheet; é o custo declarado para garantir que nenhuma decisão de execução acontece sem contexto

C. Tabs de ação

Trocar | Ordem Limite (2 tabs)
Labels completos em PT-BR — nenhuma tab truncada; Trocar é curto o suficiente para qualquer breakpoint; Ordem Limite foi auditado em PT-BR em 320 px antes de entrar em produção
Tab ativa: underline (não fill de background — evita o risco de tab preenchida criar truncamento por overflow visual)

D. Campo "Você vende" — input primário

Seletor de token: pré-preenchido com token A do par da pool (ex: USDC) — contexto herdado da entidade
Input numérico: formatação PT-BR (vírgula decimal, ponto milhar)
Eyebrow USD em tempo real: ≈ R$0 abaixo do valor; atualiza ao digitar (debounce 300ms)
Preset chips de percentual: 25% | 50% | 75% | Máx.
- Com saldo disponível: chips habilitados com fill
- Com saldo = 0 ou carteira desconectada: chips em outline (opacidade 60%) — affordance preservada, estado honesto
- Tap em chip outline: Conecte sua carteira para usar atalhos de porcentagem
Label de saldo disponível: Disponível: R$12.450,00 USDC

E. Seta de inversão de par — entre os dois campos

Ícone de setas opostas rotaciona os campos Vender/Receber
Ao inverter: tokens trocam de posição, cotação recalcula, mini-chip de identidade não muda (par canônico do pool permanece)
Nunca fecha/reabre o sheet — update local instantâneo

F. Campo "Você recebe (estimado)" — output

Seletor de token: pré-preenchido com token B do par (ex: ETH) — contexto herdado
Valor estimado: calculado, atualiza com debounce após input no campo Vender
Eyebrow USD: ≈ R$0 abaixo do valor (o delta entre o eyebrow R$ do campo Vender e o eyebrow R$ deste campo é o slippage visível sem cálculo adicional do usuário)
Em loading de cotação: spinner inline no valor estimado; campo Vender não bloqueado
Label: (estimado) em texto menor ao lado do label principal

G. Painel de detalhes — colapsado por default, expansível com tap

Tolerância ao slippage: Auto · 0,5% + chip Avançado › para override (modo avançado opt-in — não exposto no fluxo padrão)
Impacto no preço: <0,01% com cor contextual (verde < 1% / âmbar 1–3% / vermelho > 3%)
Custo estimado de gas: ~R$0,60 (estimativa baseada em gas atual × tamanho médio; copy estimado é parte do label, não footnote)
Custo total desta operação: R$X — linha-soma fechada incluindo fee de pool + gas estimado + câmbio quando aplicável; nunca esconde uma das parcelas
Rota: diagrama simplificado de nós (não string técnica USDC → ETH via 0x4...)
Botão de expansão: Ver detalhes ↓ / Ocultar ↑

H. CTA dinâmico — reflete exatamente o estado atual do preenchimento

Estado	Label do CTA
Sem wallet	`Conectar carteira`
Wallet conectada, campo vazio	`Inserir valor`
Digitando, aguardando cotação	`Calculando...` (desabilitado temporariamente)
Campos válidos, pool saudável	`Fazer swap`
Campos válidos, pool inativa	`Fazer swap mesmo assim`
Impacto de preço > 3%	`Fazer swap mesmo assim`
Impacto de preço > 10%	`Fazer swap (risco elevado)`
Saldo insuficiente	`Saldo insuficiente · Comprar USDC`
Rede errada	`Trocar para [rede] para continuar`
Erro de cotação	`Aguardando cotação` (desabilitado + retry inline)

O CTA nunca fica disabled silencioso — sempre comunica o próximo passo ou o obstáculo. "Saldo insuficiente · Comprar USDC" é ao mesmo tempo diagnóstico e saída: tap abre on-ramp contextualizado para o token correto.

I. Aviso contextual de risco inline (não-modal, não-popup)

Aparece abaixo do painel de detalhes, apenas quando impacto no preço > 3%
Badge âmbar: ⚠ Impacto de preço elevado · Esta operação pode receber menos do que o esperado
Em impacto > 10%: badge vermelho: ⚠ Impacto de preço muito alto · Verifique se este pool tem liquidez suficiente antes de confirmar
O aviso é inline — não bloqueia o CTA, não abre modal adicional. O CTA reflete o risco via label; o aviso contextualiza. Dois sinais paralelos, sem modal sobre modal (A3).

Cosméticos (estáveis após paradigma estabelecido)

Cotação em tempo real abaixo dos campos: 1 USDC = 0,000278 ETH · ≈ R$1,00
- Auto-flip quando magnitude > 1.000x: exibe 1 ETH = 3.597 USDC em vez de 1 USDC = 0,000278 ETH — legibilidade para iniciante sem precisar de notação científica (Pilar 5)
Badge de slippage no modo padrão: Auto em verde discreto ao lado do valor calculado

3. Regras de negócio

Herança de contexto: token A e token B do par são herdados do par da pool detail — campos nunca abrem vazios. Se o par é USDC/ETH, campo Vender = USDC, campo Receber = ETH.
Strip de saúde: herda os mesmos dados do chip-strip da Tela 01 (mesmo snapshot da sessão). Não faz chamada independente de dados. Se o snapshot expirou (>5 min desde a abertura da Tela 01), o strip exibe Atualizando... e recarrega em background.
Preset chips de %: calculados sobre o saldo atual do token selecionado no campo Vender. Com saldo = 0 ou carteira desconectada: chips ficam em outline mas visíveis (não desaparecem — affordance honesta). Tap em chip outline dispara prompt de conexão, não ação silenciosa.
Slippage: sempre Auto no modo padrão. O valor calculado é exibido (0,5%) para auditoria — mas a opção de override manual (Avançado ›) está colapsada por default. Usuário avançado toca Avançado › para override; sem override, Auto é sempre o valor ativo.
Auto-flip de cotação: quando 1 token A = X token B com X < 0,001, exibir automaticamente a cotação invertida 1 token B = Y token A. Threshold de flip configurável no design system; default 0,001.
CTA dinâmico: o label do CTA muda de acordo com o estado — nunca disabled sem label explicativo. A sequência de estados é linear: Sem wallet → Inserir valor → Calculando → Fazer swap (ou variante de risco/obstáculo).
Aviso de impacto: threshold 3% para âmbar, 10% para vermelho. Threshold exposto no tooltip: Impacto de preço acima de 3% indica que esta operação move o preço do pool. Quanto maior, mais você perde por slippage.
Mini-chip de identidade: nunca removido mesmo em full-screen. É o último componente a ser ocultado se o viewport for extremamente pequeno (prioridade máxima após o grab handle).
Linha-soma de custo total: sempre inclui todas as parcelas (fee de pool + gas estimado). Se uma parcela estiver indisponível (gas não calculado), exibir ~R$X (+ gas estimado) — nunca omitir a parcela nem exibir R$0 como se não houvesse custo.
Roteador/protocolo de execução: o produto decide a melhor rota de execução automaticamente. O diagrama de rota é informativo (não configura pelo usuário no modo padrão). Override de routing disponível apenas em modo avançado.

4. Estados não-triviais

Vazio (sheet aberto, campos vazios, wallet conectada) Preset chips habilitados. Cotação base exibida. CTA: Inserir valor. Strip de saúde e mini-chip visíveis. Painel de detalhes colapsado com linha-soma: --.

Loading de cotação (após input, aguardando estimativa) Campo Receber: spinner inline no valor; label (calculando). CTA: Calculando... desabilitado temporariamente. Campo Vender permanece editável — debounce de 300ms antes de nova chamada de cotação.

Erro de cotação Campo Receber: Cotação indisponível · toque para tentar novamente. CTA: Aguardando cotação (desabilitado) + ícone de retry ao lado do campo Receber. O campo Vender permanece com o valor digitado.

Saldo insuficiente Campo Vender: borda âmbar + label de saldo: Disponível: R$0,00 USDC. CTA: Saldo insuficiente · Comprar USDC. Tap → on-ramp contextualizado para USDC na rede atual (não abre on-ramp genérico). O token do campo Vender é passado como parâmetro para o on-ramp.

Carteira desconectada Sheet abre normalmente (try-before-connect). Campos exibem cotação base. Chips em outline. CTA: Conectar carteira. Tap → drawer de conexão; ao conectar, o sheet retorna ao estado exato em que estava (campos preservados).

Pool com pouca atividade Strip de saúde em âmbar com badge ⚠ Pool com pouca atividade · Slippage pode ser maior. Slippage Auto ajusta para valor mais alto (ex: 2% em vez de 0,5%) + tooltip explica o ajuste: Ajustado para pool com baixo volume — evita falha de transação. CTA mantém cor primária — o aviso é informativo, o usuário decide.

Impacto de preço alto (3–10%) Aviso âmbar inline: ⚠ Impacto de preço elevado. CTA: Fazer swap mesmo assim (label muda, cor primária mantida). Painel de detalhes exibe Impacto no preço: X% em âmbar com tooltip explicativo.

Impacto de preço muito alto (>10%) Aviso vermelho inline: ⚠ Impacto de preço muito alto. CTA: Fazer swap (risco elevado) em cor diferente do verde primário (ex: âmbar ou cor de alerta — nunca vermelho de erro; vermelho de alerta). Não bloqueia — informa e contextualiza.

Rede errada Strip de saúde mantido. Campo Vender exibe badge de rede errada. CTA: Trocar para [rede] para continuar. Tap → modal de troca de rede (mesmo comportamento da Tela 01).

Sucesso (transação enviada) Sheet fecha suavemente. Toast no rodapé da Tela 01: Swap enviado · ver transação por 5 segundos. Chip-strip da Tela 01 atualiza com novos dados assim que o snapshot expira.

Erro de transação (rejeição na wallet / timeout) Sheet permanece aberto. Toast inline no rodapé do sheet: Swap não enviado · tentar novamente. CTA volta ao estado Fazer swap. Campos preservados.

5. Microcopy crítico (PT-BR)

Elemento	Texto
Mini-chip de identidade	`USDC/ETH · v3 · Tarifa 0,05%`
Strip saúde (pool ativa)	`APR 15,8% · TVL R$135M · Vol ↑12%`
Strip saúde (pool inativa)	`⚠ Pool com pouca atividade · APR 0% · TVL R$12M · Vol ↓89%`
Tap no strip	`Ver estatísticas completas ›`
Tab Trocar	`Trocar`
Tab Ordem Limite	`Ordem Limite`
Campo Vender label	`Você vende`
Campo Receber label	`Você recebe (estimado)`
Saldo disponível	`Disponível: R$12.450,00 USDC`
Chips de preset	`25%
Tap em chip outline	`Conecte sua carteira para usar atalhos de porcentagem`
Cotação inline	`1 USDC = 0,000278 ETH · ≈ R$1,00`
Cotação auto-flip	`1 ETH = 3.597 USDC · ≈ R$18.000`
CTA: sem wallet	`Conectar carteira`
CTA: campo vazio	`Inserir valor`
CTA: calculando	`Calculando...`
CTA: pronto	`Fazer swap`
CTA: pool inativa	`Fazer swap mesmo assim`
CTA: impacto alto	`Fazer swap mesmo assim`
CTA: impacto muito alto	`Fazer swap (risco elevado)`
CTA: saldo insuficiente	`Saldo insuficiente · Comprar USDC`
CTA: rede errada	`Trocar para BNB Chain para continuar`
CTA: aguardando cotação	`Aguardando cotação`
Slippage label	`Tolerância ao slippage`
Slippage secondary	`slippage`
Slippage Auto tooltip	`Calculado pela profundidade do pool e volatilidade nas últimas 24h. Pode variar com o tamanho da sua operação.`
Slippage ajustado (pool inativa)	`Ajustado para pool com baixo volume — evita falha de transação`
Impacto de preço label	`Impacto no preço`
Impacto de preço tooltip (> 3%)	`Impacto de preço acima de 3% indica que esta operação move o preço do pool. Quanto maior, mais você perde por slippage.`
Gas label	`Custo estimado de gas`
Linha-soma label	`Custo total desta operação`
Linha-soma com gas pendente	`~R$X (+ gas estimado)`
Painel expandir	`Ver detalhes ↓`
Painel recolher	`Ocultar ↑`
Aviso impacto alto (âmbar)	`⚠ Impacto de preço elevado · Esta operação pode receber menos do que o esperado`
Aviso impacto muito alto (vermelho)	`⚠ Impacto de preço muito alto · Verifique se este pool tem liquidez suficiente antes de confirmar`
Erro de cotação	`Cotação indisponível · toque para tentar novamente`
Toast sucesso	`Swap enviado · ver transação`
Toast erro	`Swap não enviado · tentar novamente`
Avançado override label	`Avançado ›`

6. Rastreabilidade obrigatória

🟢 Herdado

Contexto herdado na ação — tokens pré-selecionados do par do pool — [uniswap visualizar-pool.md § Insight: Contexto herdado na ação]. O widget de swap abre com USDC→ETH pré-selecionados porque o par já estava em contexto. Elimina cliques e o risco de operar no par errado.
Presets chips 25% / 50% / 75% / Máx. — [uniswap visualizar-pool.md § Insight: Presets chips em qualquer decisão financeira]. Toda decisão financeira com âncora numérica recebe chips de preset. Em mobile, onde digitar é caro, o ganho é maior.
Aviso inline de risco durante preenchimento (não popup ao final) — [uniswap visualizar-pool.md § Insight: Sinalização de risco/variação in-place sem friction transacional]. Aviso de pool inativa ou impacto alto fica visível durante todo o preenchimento, não após o CTA.
CTA dinâmico descrevendo o gap atual — [pancake-final § Pilar 6 — CTA dinâmico + Default contextual em camadas]. CTA nunca disabled silencioso — comunica o próximo passo: "Inserir valor" → "Calcular" → "Fazer swap".
Try-before-connect — sheet abre sem wallet — [uniswap-final § Ação imediata sem commit nem onboarding]. Usuário vê cotação e campos antes de conectar carteira.
Equivalente fiat (R$) abaixo de cada campo de input — [uniswap-final § Múltiplas representações do mesmo dado + bidirecionalidade]. Todo token amount exibe equivalente em moeda local nos momentos críticos.
Slippage Auto com valor exposto para auditoria — [pancake-final § Insight: Defaults pró-iniciante sem pedir permissão]. Slippage Auto calculado e visível; override manual colapsado para modo avançado.

🔴 Corrige

Strip de saúde + mini-chip de identidade no topo do sheet — corrige [uniswap visualizar-pool.md § Fricção estrutural: Desacoplamento widget↔contexto da pool no ato de decidir]. Esta é a fricção mais crítica do fluxo inteiro: modal/sheet de execução sobrepõe o chart e os KPIs exatamente no momento de decisão. O mini-chip + strip garantem que nenhum ato de decisão acontece sem contexto — custo: ~60 px no topo do sheet.
Preset chips com estado honesto (outline quando saldo = 0) — corrige [uniswap visualizar-pool.md § Fricção estrutural: Affordance sem estado honesto]. Nos concorrentes: chips com aparência habilitada com saldo = 0 — tap em Máx. preenche 0 sem feedback. Na Kotai: chips outline + tap dispara prompt de conexão.
Eyebrow USD em ambos os campos (Vender e Receber) — corrige [uniswap visualizar-pool.md § Fricção estrutural: Unidade técnica não traduzida para intuitiva]. Nos concorrentes: cotação USD no campo Comprar, ausente no campo Vender — assimetria que esconde o slippage real. O delta entre os dois eyebrows R$ é o slippage visível sem cálculo.
CTA com label de obstáculo (não disabled silencioso) — corrige [pancake-final § Fricção 10 — CTA disabled silencioso sem comunicar o gap]. "Criar Ordem Limite" / "Fazer swap" disabled em múltiplos estados sem indicar o que falta.
Mini-chip de identidade persistente em full-screen — corrige [uniswap visualizar-pool.md § Fricção estrutural: Desacoplamento widget↔contexto]. Na transição para Ordem Limite, o header sticky do pool desaparecia — usuário perdia até a âncora de "qual pool estou operando".

🟡 Captura

Mini-chip + strip de saúde como padrão "contexto persistente em sheet" — captura [uniswap visualizar-pool.md § Oportunidade 1: Contexto persistente no ato de operar]. Todos os concorrentes (Uniswap, PancakeSwap, 1inch, Curve): quando o widget abre, métricas de saúde ficam atrás do overlay. Hipótese de diferenciação: nenhuma decisão de execução acontece sem contexto em qualquer sheet de ação da Kotai — o padrão se torna parte do design system, não solução pontual.
Eyebrow USD + auto-flip de cotação — captura [uniswap visualizar-pool.md § Oportunidade 4: Tradução técnica→intuitiva em campos de unidade não-fiat]. Todos os concorrentes mantêm unidade técnica como nominal (0,0000550306 ETH). Hipótese: ≈ R$0,21 muda a decisão de executar de forma visceral — usuário decide no referencial que entende.
CTA "Saldo insuficiente · Comprar [token]" com on-ramp contextualizado — captura [pancake-final § Pilar 6 — CTA dinâmico] + [uniswap-final § Pilar 1 — Localização BR/LatAm como infraestrutura]. Todos os concorrentes: saldo insuficiente → disabled ou mensagem isolada sem saída. Hipótese: CTA como diagnóstico + ação embutida reduz abandono no ponto de primeira barreira real.
Linha-soma fechada de custo total — captura [pancake-final § Pilar 4 — Transparência financeira ativa]. Todos os concorrentes: fee de pool ou gas, nunca soma. Hipótese: Custo total desta operação: R$X constrói confiança antes do commit — usuário sabe exatamente o que está pagando.
Slippage ajustado automaticamente para pool inativa (com tooltip explicativo) — captura [uniswap-final § Pilar 5 — Simulação ativa e assistência pré-commit]. Todos os concorrentes: slippage Auto com valor fixo sem adaptação ao estado da pool. Hipótese: slippage que se ajusta à saúde do pool evita falha de transação sem o usuário precisar entender o mecanismo.

⚪ Novo

Threshold específico do auto-flip (0,001): o conceito de auto-flip de preço por magnitude tem origem em [pancake-final § Pilar 7 — Mobile-first interaction + Localização BR/LatAm como infraestrutura] ("Auto-flip de preço por magnitude — detectar quando ratio nominal < 0,01 e inverter automaticamente") e é capturado como 🟡 Diferenciador acima via Oportunidade 4 do consolidado. O que é ⚪ Novo é exclusivamente o valor do threshold (0,001) que define o ponto de ativação — esse valor específico não tem origem nos relatórios. Justificativa: 0,001 é o limiar abaixo do qual 4+ casas decimais antes do ponto tornam o número ilegível para iniciante sem notação científica. Evidência a coletar: sessões de usability com 5 iniciantes testando pares com magnitude extrema (ex: SHIB/ETH) — observar se o número "virado" confunde ou esclarece, e ajustar threshold se necessário.
Toast de erro persistente no rodapé do sheet (transação rejeitada): o padrão de toast de erro no interior do sheet não tem origem direta nos relatórios. Justificativa: fechar o sheet ao erro força o usuário a reabrir e repreencher os campos — custo de UX desnecessário quando o erro é recuperável. Evidência a coletar: comparar taxa de retentativa entre "toast + campos preservados" vs "sheet fecha ao erro" em teste A/B.

7. Trade-offs e segunda ordem

Os 60 px do mini-chip + strip de saúde são inegociáveis em termos de segurança, mas têm custo visual: em pool muito saudável (APR alto, TVL alto, Volume alto), o strip é informação positiva que compete com o campo de input. Mitigação: coloração discreta (verde quase neutro) em pool saudável; o strip "desaparece" visualmente quando não há alarme, e "aparece" em âmbar quando importa.

Dois estilos do mesmo componente chip (fill vs outline): o estado outline dos preset chips requer dois estados de estilo para o mesmo componente no design system. Custo: mais QA visual; ganho: affordance honesta elimina uma das principais causas de confusão de iniciante em primeiro uso de DEX (tap em botão que parece habilitado mas não faz nada).

CTA com múltiplos labels aumenta superfície de tradução: cada estado do CTA é uma string PT-BR. 8 estados = 8 strings × N idiomas. Mitigável com template system ({ação} · {motivo}) que reduz a variação para combinações parametrizadas, não strings completamente independentes.

Oracle de USD para eyebrow nos campos: o eyebrow ≈ R$X requer feed de preço fresco (< 30s de staleness). Com dado stale: mudar a cor do eyebrow para cinza claro + tooltip Cotação pode estar desatualizada. Nunca remover o eyebrow quando stale — o usuário precisa ver o dado mesmo que impreciso; o sinal de imprecisão é o suficiente.

Slippage Auto adaptativo por pool: calcular slippage pelo estado da pool requer: (1) dados de profundidade de liquidez em tempo real, (2) modelo de impacto de preço por tamanho de swap, (3) volatilidade histórica 24h. Complexidade de implementação alta. Fallback aceitável: Auto fixo por tier de pool (pool morta = 2%; pool ativa com TVL > $1M = 0,5%; pool nova = 1%) — heurística pior mas segura. O tooltip deve declarar qual critério está ativo.

Conflito Pilar 3 vs Pilar 4 (Risk signaling vs Transparência financeira): o strip de saúde em âmbar pode ser lido como aviso de risco de segurança (Pilar 3) quando na verdade é aviso de eficiência de execução (Pilar 4 — slippage). Resolução: copy do strip é sempre sobre execução (Slippage pode ser maior), nunca sobre segurança do contrato — não misturar os dois sinais. Segurança de contrato (token suspeito, pool não auditada) usa badge de risco diferente, com ícone de escudo e não de alerta operacional.

Visualizar Pool — Tela 04: Widget de Swap contextualizado (Bottom Sheet)

1. Função da tela

Permite ao usuário iniciar um swap de um dos tokens do par diretamente do contexto da pool — sem perder os sinais de saúde do pool no momento em que preenche os campos. Foco: iniciante (principal) + intermediário em decisão rápida.

2. Componentes / elementos

Estrutural

Chip-strip de saúde (~36 px, sticky no topo do sheet, abaixo do grab handle — antes de qualquer campo)

Formato: APR X% · TVL R$ XXX M · Vol ↑/↓ XX%
Cor do strip: verde discreto quando pool ativa; âmbar quando Vol24h / TVL < 0,001 OU Vol24h < R$ 5.000
Tap no strip → drawer de saúde desliza por baixo (não modal) com caption narrativa: "Pool com pouca atividade nas últimas 24h. Slippage pode ser maior que o habitual."
Sourced do mesmo snapshot da tela principal (mesmo timestamp dos KPIs de T01 — coerência intra-tela, sem divergência de dados)

Mini-chip de identidade (1 linha discreta integrada ao topo do sheet)

WISE/ETH v2 0,3% — âncora de "em qual pool estou operando"
Persiste mesmo quando o sheet expande para cobrir mais da viewport; nunca colapsa

Tabs do widget: Trocar | Limite ▾

Duas tabs fullwidth — sem truncamento PT-BR (quatro tabs no Uniswap causavam Vẽd cortado)
Limite ▾ abre Tela 05 como novo contexto de sheet — não expande esta tela

Campo "Você paga" (input principal)

Input numérico; teclado numérico nativo em mobile
Eyebrow abaixo do valor: ≈ R$ XXX (atualiza em tempo real a partir do FX rate)
Presets abaixo do campo: 25% · 50% · 75% · Tudo
- Sem wallet conectada: chips em outline 60% de opacidade; tap → toast "Conecte sua carteira para usar atalhos de porcentagem"
- Com wallet: preenchimento direto, atualiza "Você recebe" em tempo real

Campo "Você recebe" (calculado)

Eyebrow ≈ R$ XXX abaixo do valor — o delta entre os dois eyebrows é o slippage visível sem cálculo
Badge inline âmbar quando impacto de preço > 0,5%: ⚠ Você vai receber menos que o estimado — liquidez limitada
Badge âmbar de pool inativa quando threshold atingido: ⚠ Pool com pouca atividade · Slippage pode ser maior

Bloco de transparência (colapsado por default)

Estado colapsado: Custo estimado: ~R$ XX · Slippage: 0,5% em cinza secundário
Estado expandido: Taxa de rede / Impacto de preço / Rota via [protocolo]
Expansão por tap no bloco — nenhum CTA necessário para ver o breakdown

Estimativa de gas no estado vazio (cosmético-estrutural)

Micro-label abaixo dos campos antes de qualquer digitação: Custo estimado de rede: ~R$ XX (para swap típico nesta pool)
Calculado a partir: gas atual × tamanho médio de swap nesta pool nos últimos 30 dias
Âncora explícita de heurística — não promessa de valor exato

CTA dinâmico (fullwidth, sticky no rodapé do sheet)

Inserir valor — campo vazio
Conectar carteira — sem wallet
Confirmar swap — preenchido, pool ativa
Confirmar mesmo assim — pool inativa (cor laranja, não verde)
Confirmar com slippage alto — impacto > 2% (cor laranja)
Saldo insuficiente de [TOKEN] — sem saldo (disabled + link Comprar [TOKEN] que redireciona para T06)

Cosmético

Ícone de inversão de par (↕) entre os dois campos — funcionalmente herda da convenção Uniswap/Pancake
Animação de loading spinner no campo "Você recebe" durante cálculo de cotação
Grab handle no topo do sheet (convenção mobile)

3. Regras de negócio

Par pré-selecionado: herda do contexto da pool. Token A (ex: WISE) = "Você paga"; Token B (ex: ETH) = "Você recebe". Herança ocorre automaticamente — usuário não seleciona manualmente.

Inversão de par: ao tocar no ↕, os dois campos invertem (valores e tokens); âncora de orientação no mini-chip atualiza de WISE/ETH ↕ para ETH/WISE ↕. Inversão persiste enquanto o sheet estiver aberto; fecha o sheet → próxima abertura volta à orientação canônica (A/B conforme listagem da pool).

Threshold de pool inativa: Vol24h / TVL < 0,001 OU Vol24h < R$ 5.000. Ambos os critérios precisam ser atendidos para disparar badge âmbar E CTA laranja. Somente um critério ativo → só badge, CTA permanece verde.

CTA laranja + delay de 2s: quando pool inativa, o toque no CTA Confirmar mesmo assim espera 2 segundos antes de habilitar o envio. O delay é visível (progress ring no botão) — implementa fricção intencionada para ação com risco elevado, análogo ao type-to-confirm do Expert Mode.

Prioridade de estados do CTA (do mais para o menos prioritário): rede errada > sem wallet > saldo insuficiente > campo vazio > slippage alto > pool inativa > pronto.

Snapshot compartilhado: chip-strip de saúde usa o mesmo snapshot de KPIs que T01 carregou (timestamp idêntico) — garante que APR/TVL/Vol no strip batem com os valores que o usuário viu antes de abrir o sheet. Atualiza quando T01 refresca (polling 30s).

Eyebrow BRL: fonte = oracle FX BRL/USD atualizado a cada 30s. Quando dado envelhece > 30s → eyebrow exibe em cinza claro com (valor aproximado) ao lado para sinalizar staleness sem alarme.

4. Estados não-triviais

Estado	Feedback visual	Recuperação
Vazio	Campos em branco; presets visíveis (outline sem wallet); estimativa de gas heurística; CTA `Inserir valor` disabled	—
Loading de cotação	Spinner no campo "Você recebe" + `Calculando...`	Campo "Você paga" permanece editável durante loading
Pool inativa	Chip-strip âmbar + badge âmbar no campo "Você recebe" + CTA laranja `Confirmar mesmo assim` + drawer de saúde disponível	Tap no chip-strip → contexto narrativo de por que a pool está inativa
Saldo insuficiente	CTA `Saldo insuficiente de WISE` disabled + link inline `Comprar WISE`	Link redireciona para T06 (on-ramp) com token pré-selecionado
Slippage alto (> 2%)	Badge âmbar no campo "Você recebe" + bloco de transparência abre automaticamente + CTA laranja `Confirmar com slippage alto`	Usuário pode ajustar valor ou continuar com consciência
Sem wallet	Chips de presets em outline 60%; CTA `Conectar carteira`	Tap no CTA abre fluxo de conexão sem fechar o sheet
Gas alto	Estimativa de gas atualizada no bloco de transparência em âmbar + `Rede congestionada — custo pode ser maior`	Usuário pode aguardar ou continuar
Confirmando on-chain	CTA em spinner + `Aguarde — enviando para a rede` + campos bloqueados	—
Sucesso	Sheet fecha; toast flutuante: `Swap confirmado · WISE → ETH · ver transação` (link para hash)	—
Erro de transação	Sheet mantém preenchimento; mensagem de causa específica (ex: `Slippage excedido. Aumente a tolerância ou reduza o valor.`) + CTA `Tentar novamente`	Preenchimento mantido para não forçar redigitação
Rede errada	Banner sticky no topo do sheet `Mude para [Rede] para usar esta pool`; todos os CTAs desabilitados	Tap no banner → orientação de como trocar a rede
Eyebrow BRL stale (> 30s)	Eyebrow em cinza claro com `(valor aproximado)`	Atualiza automaticamente quando oracle responde

5. Microcopy crítico (PT-BR)

CTAs dinâmicos

Inserir valor
Conectar carteira
Confirmar swap
Confirmar mesmo assim — pool inativa
Confirmar com slippage alto — impacto > 2%
Saldo insuficiente de [TOKEN]
Comprar [TOKEN] — link inline ao lado do CTA de saldo insuficiente

Tooltips e avisos inline

Chip-strip âmbar: Pool com pouca atividade nas últimas 24h. Slippage pode ser maior que o habitual.
Badge âmbar campo "Você recebe": ⚠ Você vai receber menos que o estimado — liquidez limitada
Badge pool inativa no campo: ⚠ Pool com pouca atividade · Slippage pode ser maior
Estimativa de gas: Custo estimado de rede: ~R$ XX (para swap típico nesta pool)
Chips sem wallet: Conecte sua carteira para usar atalhos de porcentagem (toast ao tap)
Orientação de par: WISE/ETH ↕ / ETH/WISE ↕
Gas alto: Rede congestionada — custo pode ser maior
Eyebrow stale: (valor aproximado)

Mensagens de erro

Slippage excedido: Slippage excedido. Aumente a tolerância ou reduza o valor.
Transação recusada: Transação recusada. [causa específica]. Tente novamente.
Rede errada: Mude para [Rede] para usar esta pool
Sem provider: Sem liquidez disponível para este par no momento.

Toast de sucesso

Swap confirmado · WISE → ETH · ver transação

6. Rastreabilidade obrigatória

🟢 Herdado

Par pré-selecionado ao abrir o widget — tokens da pool já em contexto, sem seleção manual: [uniswap-consolidado visualizar-pool § Insight 1 — Contexto herdado na ação]
Presets chips 25% / 50% / 75% / Tudo no campo de saldo — elimina cálculo de proporção: [uniswap-consolidado visualizar-pool § Insight 2 — Presets chips em qualquer decisão financeira]
Aviso de pool inativa visível durante todo o preenchimento, não popup no final: [uniswap-consolidado visualizar-pool § Insight 3 — Sinalização de risco inline sem friction transacional]
CTA descrevendo o gap específico ("Inserir valor", "Saldo insuficiente de X") em vez de CTA genérico bloqueado: [pancake-final § Insight 5 — Transparência proativa antes do CTA]
Slippage Auto adaptativo como default (não valor fixo estático): [pancake-final § Insight 1 — Defaults pró-iniciante]

🔴 Corrige

Bottom sheet cobre as Estatísticas ao subir — corrigido pelo chip-strip de saúde que leva APR/TVL/Vol para dentro do sheet: [uniswap-consolidado visualizar-pool § Fricção estrutural 1 — Desacoplamento widget↔contexto da pool]
Chips de percentual com affordance desonesta quando saldo = 0 — corrigido por outline 60% + toast explicativo ao tap: [uniswap-consolidado visualizar-pool § Fricção estrutural 8 — Affordance sem estado honesto]
Campos de swap sem eyebrow em fiat (iniciante não decoda delta entre tokens em unidade técnica) — corrigido por eyebrow BRL em ambos os campos; delta = slippage visível: [uniswap-consolidado visualizar-pool § Fricção estrutural 7 — Unidade técnica não traduzida para intuitiva]
Tabs truncadas em PT-BR (Vẽd ao invés de "Vender") — corrigido por redução para 2 tabs fullwidth: [uniswap-consolidado visualizar-pool § Fricção estrutural 2 — Truncamentos PT-BR sistêmicos]
CTA verde para ação potencialmente danosa (swap em pool morta) — corrigido por CTA laranja: [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência]

🟡 Captura

Chip-strip de saúde persistente no topo de qualquer sheet de ação contextualizada — nenhum concorrente implementa; hipótese: nenhuma decisão de execução acontece sem contexto de saúde da pool; pool morta sinalizada antes de qualquer input: [uniswap-consolidado visualizar-pool § Oportunidade 1 — Contexto persistente no ato de operar]
Estimativa de gas no estado vazio (antes de qualquer digitação) — nenhum concorrente exibe; hipótese: iniciante decide se "vale tentar" antes de preencher; reduz abandono pós-preenchimento por surpresa com custo: [uniswap-consolidado visualizar-pool § Oportunidade 2 — Pré-visualização rica do swap antes de input]
Eyebrow BRL em ambos os campos de swap — delta entre eyebrows = slippage percebido sem cálculo; hipótese: iniciante percebe slippage real antes de confirmar: [uniswap-consolidado visualizar-pool § Oportunidade 4 — Tradução técnica→intuitiva]
Presets chips em ambos os breakpoints (não só mobile) — hipótese: paridade de affordance elimina assimetria de experiência: [uniswap-consolidado visualizar-pool § Oportunidade 7 — Quick-amount chips trazidos para desktop]

⚪ Novo

CTA laranja com delay de 2s para pool inativa — sem precedente direto nos relatórios analisados. Justificativa: impede execução irrefletida em pool morta sem bloquear completamente o acesso; o laranja segue a hierarquia de consequência do Pilar 3; o delay replica o princípio de fricção intencionada do type-to-confirm [pancake-final § Insight 2 — Defesa em camadas] sem exigir digitação de texto. Threshold precisa ser conservador: validar com dados reais de pools com baixa atividade legítima (ex: pools de stablecoins pouco usadas mas saudáveis) para evitar falsos positivos que irritam o intermediário. Validação futura: A/B de abandono vs execução com/sem CTA laranja + delay.

7. Trade-offs e segunda ordem

Chip-strip de saúde (+36 px universais): custo de layout em todo bottom sheet do produto que herde o padrão. Aceitar — o padrão "nenhuma ação acontece sem contexto de saúde" vale o custo de espaço.

Estimativa de gas heurística: requer pipeline tamanho médio de swap nos últimos 30 dias por pool — infra não-trivial. Alternativa degradada: estimativa por pool-type genérica (v2 vs v3) sem histórico da pool específica — menos precisa mas viável no MVP.

Eyebrow BRL em campos de swap: requer oracle FX BRL/USD com SLA de 30s + tratamento de staleness. Dado stale > 30s mostrando valor desatualizado é pior que silêncio — o tratamento de cor diferente ao envelhecer é obrigatório.

2 tabs vs 4 tabs: comprime o fluxo de ordem-limite para T05 — custo de navegação (1 tap a mais para abrir ordem-limite). Ganho: nenhum label primário truncado; strip de identidade mais limpo.

CTA com 5+ estados: prioridade de estados precisa ser codificada explicitamente (rede errada > sem wallet > sem saldo > campo vazio > slippage alto > pool inativa > pronto) — complexidade de estado no componente, não opcional.

i18n: todo microcopy tem custo de tradução para ES e outros locales LatAm. Eyebrow BRL vira eyebrow em moeda local por locale — custo crescente com expansão geográfica.

Visualizar Pool — Tela 05: Widget de Ordem-Limite contextualizado (Bottom Sheet)

1. Função da tela

Permite ao usuário criar uma ordem-limite no par da pool — com preço-alvo, quantidade e expiração — sem progressive disclosure tardio de campo crítico (Expiração), com tradução de unidade técnica para fiat, e sem perder a âncora de identidade da pool mesmo quando o sheet expande para full-screen. Foco: intermediário (principal), com guardrails ativos para iniciante.

2. Componentes / elementos

Estrutural

Chip-strip de saúde + mini-chip de identidade (≡ Tela 04)

Mesmos componentes e regras de T04 — consistência cross-sheet do fluxo
Quando sheet expande para full-screen: mini-chip de identidade WISE/ETH v2 0,3% persiste no header fixo superior — nunca colapsa, nunca some

Campo "Você vende"

Input numérico; eyebrow ≈ R$ XXX abaixo do valor
Presets 25% / 50% / 75% / Tudo com mesma regra de affordance honesta de T04 (outline sem wallet; toast explicativo ao tap)

Campo "Quando 1 [WISE] valer" (preço-alvo — componente central da tela)

Label dinâmico:
- Estado vazio: Preço-alvo
- Estado com auto-preenchimento de mercado: Quando 1 WISE valer (prosa contextual substitui jargão técnico)
Input em unidade do par (ex: ETH) + eyebrow ≈ R$ X,XX abaixo — precisão técnica preservada, âncora intuitiva anotada
Chip "Mercado" como primeiro e pré-selecionado no estado inicial: Mercado: 0,0000550306 ETH (≈ R$ 0,21); tap → preenche com preço atual
Chips de markup com direção semântica explícita e preço resultante em segunda linha:
- Quando direção = vender WISE (WISE → ETH): +1% mais caro / +5% mais caro / +10% mais caro
- Quando direção = comprar WISE (ETH → WISE): −1% mais barato / −5% mais barato / −10% mais barato
- Segunda linha de cada chip: = 0,0000578 ETH (≈ R$ 0,22) — valor resultante antes do tap
Aviso inline sempre visível: ⚠ Pode não executar — mercado precisa atingir esse preço + link Saber mais que abre drawer educacional (não modal bloqueante)

Campo "Você recebe" (calculado automaticamente)

Read-only; calculado quando "Você vende" E "Quando 1 WISE valer" estão preenchidos
Eyebrow ≈ R$ XXX
Estado vazio do campo: — (travessão) — sem placeholder que simula dado

Seção de Expiração — sempre visível, estado vazio incluído

Default pré-selecionado: 1 semana
Chips: 1 dia · 1 semana · 1 mês · 1 ano
Chip 1 ano: eyebrow ⚠ acima do chip + microcopy condicional inline abaixo dos chips quando selecionado: Ordens longas mantêm aprovação do contrato ativa por 1 ano. Você pode cancelar antes disso.
Seção sempre visível independentemente do preenchimento dos campos acima — elimina progressive disclosure tardio de campo crítico

Bloco de transparência (colapsado por default)

Colapsado: Taxa de criação: ~R$ XX · Expira em 1 semana
Expandido: Taxa de rede / Taxa da plataforma (X%) / Expiração / Contrato de ordem-limite
Link Saber mais sobre ordens-limite → drawer educacional de 60% da viewport (não modal bloqueante)

CTA dinâmico (fullwidth, sticky no rodapé)

Inserir valor — campos vazios
Definir preço-alvo — só "Você vende" preenchido
Confirmar ordem — tudo preenchido, pool ativa
Confirmar swap imediato — preço-alvo < preço de mercado (cor laranja, badge âmbar)
Conectar carteira — sem wallet
Saldo insuficiente de [TOKEN] — sem saldo

Cosmético

Grab handle no topo do sheet
Divisor sutil entre seção de campos (Você vende / Preço-alvo / Você recebe) e seção Expiração
Ícone de informação ⓘ ao lado de "Expiração" abre o mesmo drawer educacional que o link do campo de preço-alvo

3. Regras de negócio

Par e direção herdados do contexto da pool: quando o usuário chega a T05 vindo do chip Limite ▾ de T04, o par e a direção são os mesmos da sessão de T04 naquele momento (incluindo eventual inversão de par).

Chips de markup invertem automaticamente ao trocar direção: se o usuário tocar na setinha de inversão de par, os chips +X% mais caro viram −X% mais barato e os valores resultantes são recalculados. A inversão é instantânea, sem recarregamento.

Expiração sempre visível: o campo de Expiração não está sob nenhuma condição de progressive disclosure. Mesmo com todos os campos de input vazios, os chips de expiração estão visíveis e o default 1 semana já está selecionado. Isso é comportamento obrigatório — não opcional.

Aviso de allowance longa (chip 1 ano): ao selecionar 1 ano, microcopy aparece inline diretamente abaixo da linha de chips — sem modal, sem bloqueio. É Tier 2 (risco moderado e reversível: o usuário pode cancelar a ordem antes do vencimento). Não aplica type-to-confirm para este caso.

Preço-alvo abaixo do mercado = execução imediata: quando o valor do campo "Quando 1 WISE valer" for menor que o preço de mercado atual no momento de confirmar (para venda), badge âmbar inline aparece: Preço abaixo do mercado — vai executar como swap imediato. CTA muda para Confirmar swap imediato (laranja). Esse caso é Tier 2 — não bloqueia, mas exige ciência explícita da mudança de modalidade.

Preço-alvo muito distante (> 50% acima do mercado): aviso adicional inline: Preço muito distante do mercado — ordem pode expirar sem executar. Não bloqueia a criação, mas permanece visível durante todo o preenchimento.

Mini-chip de identidade em full-screen: quando o sheet expande para ocupar mais da viewport (ex: teclado aberto + scroll longo), o header do sheet com WISE/ETH v2 0,3% permanece fixo no topo. O chip-strip de saúde acompanha colapsado em 1 linha (APR X% · Vol ↓XX% abreviado).

Prioridade de estados do CTA (do mais para o menos prioritário): rede errada > sem wallet > saldo insuficiente > campos vazios > parcial (só "Você vende") > preço < mercado > tudo preenchido.

4. Estados não-triviais

Estado	Feedback visual	Recuperação
Vazio	Todos os campos em branco; Expiração visível com `1 semana` pré-selecionada; CTA `Inserir valor` disabled	—
Parcial (só "Você vende" preenchido)	Campo "Você recebe" mostra `—`; CTA `Definir preço-alvo`	Foco no campo de preço-alvo ao tocar no CTA
Loading de preço de mercado	Chip "Mercado" em spinner até preço ser carregado	Campos de markup desabilitados até o preço de mercado chegar
Preço-alvo < mercado	Badge âmbar inline: `Preço abaixo do mercado — vai executar como swap imediato`; CTA laranja `Confirmar swap imediato`	Usuário pode ajustar o preço ou confirmar ciente da mudança
Preço-alvo muito distante (> 50%)	Aviso inline abaixo do campo: `Preço muito distante do mercado — ordem pode expirar sem executar`	Persiste durante todo o preenchimento; não bloqueia
Expiração 1 ano selecionada	Microcopy inline condicional: `Ordens longas mantêm aprovação do contrato ativa por 1 ano. Você pode cancelar antes disso.`	Não bloqueia; informação ativa o usuário sem friction adicional
Sem wallet	Chips de presets em outline 60%; CTA `Conectar carteira`	Abre fluxo de conexão sem fechar o sheet
Saldo insuficiente	CTA `Saldo insuficiente de [TOKEN]` disabled + link `Comprar [TOKEN]` → T06	Redireciona com token pré-selecionado
Rede errada	Banner sticky `Mude para [Rede] para criar ordens nesta pool`; CTAs desabilitados	Orientação de troca de rede
Confirmando on-chain	CTA em spinner + `Aguarde — criando a ordem`; campos bloqueados	—
Sucesso	Sheet fecha; toast: `Ordem criada · WISE → ETH quando 1 WISE = R$ X,XX · ver ordem`	—
Erro	Mensagem de causa específica; preenchimento mantido; CTA `Tentar novamente`	—
Oracle de mercado indisponível	Chip "Mercado" em estado `—` com tooltip `Preço de mercado indisponível. Insira manualmente.`	Campos de markup também em `—`; input manual habilitado

5. Microcopy crítico (PT-BR)

CTAs dinâmicos

Inserir valor
Definir preço-alvo
Confirmar ordem
Confirmar swap imediato (preço < mercado)
Conectar carteira
Saldo insuficiente de [TOKEN]
Comprar [TOKEN] (link inline)
Tentar novamente

Labels dinâmicos

Campo de preço-alvo — vazio: Preço-alvo
Campo de preço-alvo — preenchido: Quando 1 WISE valer
Chip de mercado: Mercado: 0,0000550306 ETH (≈ R$ 0,21)
Chips de markup — venda: +1% mais caro / +5% mais caro / +10% mais caro
Chips de markup — compra: −1% mais barato / −5% mais barato / −10% mais barato
Segunda linha do chip (valor resultante): = 0,0000578 ETH (≈ R$ 0,22)

Avisos inline

Aviso de não-execução: ⚠ Pode não executar — mercado precisa atingir esse preço
Preço abaixo do mercado: Preço abaixo do mercado — vai executar como swap imediato
Preço muito distante: Preço muito distante do mercado — ordem pode expirar sem executar
Expiração 1 ano: Ordens longas mantêm aprovação do contrato ativa por 1 ano. Você pode cancelar antes disso.
Oracle indisponível: Preço de mercado indisponível. Insira manualmente.

Mensagens de erro e confirmação

Rede errada: Mude para [Rede] para criar ordens nesta pool
Toast de sucesso: Ordem criada · WISE → ETH quando 1 WISE = R$ X,XX · ver ordem
Chip de identidade em full-screen: WISE/ETH v2 0,3%

6. Rastreabilidade obrigatória

🟢 Herdado

Presets chips em campo de valor com affordance honesta: [uniswap-consolidado visualizar-pool § Insight 2 — Presets chips em qualquer decisão financeira]
Aviso "pode não executar" como cidadão de primeira classe, sempre visível — não tooltip hover: [uniswap-consolidado visualizar-pool § Insight 3 — Sinalização de risco inline sem friction transacional]
CTA descrevendo o gap específico em cada estado: [pancake-final § Insight 5 — Transparência proativa antes do CTA]
Mini-chip de identidade sticky mesmo em full-screen — herda o padrão de sticky identidade mobile de T01: [uniswap-consolidado visualizar-pool § Insight 5 — Sticky de identidade em mobile]

🔴 Corrige

Header com identidade da pool some ao expandir para full-screen — corrigido pelo mini-chip de identidade fixo no topo do sheet em qualquer tamanho de viewport: [uniswap-consolidado visualizar-pool § Fricção estrutural 1 — Desacoplamento widget↔contexto, manifestação full-screen Tela 09]
Chips de markup com direção ambígua (+5% — em relação a qual lado?) — corrigido por chips semânticos com direção explícita (+5% mais caro) + inversão automática ao trocar direção: [uniswap-consolidado visualizar-pool § Ponto isolado — Fricção Tela 09 — direção de markup ambígua]
Expiração como progressive disclosure tardio (só aparece após preenchimento de preço-alvo) — corrigido por exibição sempre visível com default 1 semana pré-selecionado: [uniswap-consolidado visualizar-pool § Fricção estrutural 8 — Affordance sem estado honesto, manifestação Tela 10]
Chip 1 ano sem aviso de allowance longa — corrigido por microcopy inline condicional ao selecionar o chip: [uniswap-consolidado visualizar-pool § Ponto isolado — Fricção Tela 10 — chip 1 ano sem aviso de risco]
Unidade técnica (ETH decimal bruto) sem âncora intuitiva no campo de preço-alvo — corrigido por eyebrow BRL e chip "Mercado" com preço em R$: [uniswap-consolidado visualizar-pool § Fricção estrutural 7 — Unidade técnica não traduzida para intuitiva]

🟡 Captura

Copy dinâmico: label muda de "Preço-alvo" para "Quando 1 WISE valer" ao auto-preencher — o Uniswap usa essa prosa contextual (vs jargão no estado vazio); hipótese: iniciante lê "Quando 1 WISE valer" e entende o que o campo pede sem documentação: [uniswap-consolidado visualizar-pool § Ponto isolado — Tela 10, copy dinâmico herdável]
Eyebrow BRL em campo de preço técnico (ETH decimal) — nenhum concorrente anota o intuitivo ao lado do técnico; hipótese: ≈ R$ 0,21 transforma 0,0000550306 ETH de jargão em referência de valor acionável: [uniswap-consolidado visualizar-pool § Oportunidade 4 — Tradução técnica→intuitiva em campos de unidade não-fiat]
Chip-strip de saúde persistente em full-screen — nenhum concorrente carrega contexto de pool ao expandir; hipótese: intermediário sabe em qual pool está criando a ordem mesmo quando o sheet ocupa a tela inteira: [uniswap-consolidado visualizar-pool § Oportunidade 1 — Contexto persistente no ato de operar]
Aviso de preço muito distante do mercado (> 50%) — padrão de feedback dinâmico de execução de ordens; hipótese: aviso persistente durante todo o preenchimento (não só no CTA) reduz criação de ordens com probabilidade de execução próxima de zero, evitando taxa de criação desperdiçada: [pancake-final § Pilar 4 — Educação contextual + transparência financeira; "Feedback dinâmico de probabilidade de execução em ordens-limite"] + [uniswap-final § Pilar 5 — Simulação ativa e assistência pré-commit; "substitui disclaimer estático por indicador atualizado em tempo real"]. O threshold específico de 50% é ⚪ (ver ⚪ abaixo).

⚪ Novo

Chips de markup com preço resultante em segunda linha — sem precedente nos relatórios. Os chips de todos os concorrentes são "cégos" (+5% sem âncora de valor). Duas linhas por chip entregam delta relativo + valor absoluto no mesmo atalho, eliminando a ambiguidade de magnitude. Custo: +12 px por chip × 3 chips = +36 px na seção. Validação futura: medir conversão de fill do campo preço-alvo com vs sem segunda linha (hipótese: a âncora de valor no chip reduz abandono nesse campo).
Badge + CTA Confirmar swap imediato quando preço-alvo < mercado — sem precedente nos relatórios. Justificativa: evita que o usuário pague taxa de criação de ordem-limite por uma operação que vai executar imediatamente como swap (perdendo a semântica de "ordem-limite" e pagando fee extra). O erro acontece em DEXs com order-limit quando o usuário define o preço sem verificar o mercado atual. Validação futura: medir % de ordens com preço < mercado vs taxa de execução imediata com e sem o badge.
Threshold de 50% para classificar preço como "muito distante": o padrão de aviso dinâmico de execução improvável é 🟡 (ver acima), mas o critério exato de 50% não tem precedente direto nos relatórios. Justificativa: threshold conservador o suficiente para não gerar falsos positivos em mercados voláteis (desvios de 20–30% são comuns em altcoins de baixa liquidez); inequívoco o suficiente para que a hipótese central valha (ordem 50% acima do mercado tem probabilidade próxima de zero de executar em 1 semana). Validação futura: medir % de ordens criadas com desvio > 50% vs taxa de execução observada; calibrar conforme o percentil real de "nunca executa em 1 mês".

7. Trade-offs e segunda ordem

Mini-chip de identidade em full-screen: adiciona ~24 px ao header em modo full-screen. Custo mínimo; ganho crítico: usuário que opera em pool WISE/ETH v2 0,3% nunca confunde com WISE/ETH v3 0,05% ao retornar o olhar ao topo da tela.

Expiração sempre visível: +50 px no estado vazio do sheet (seção sempre presente). Aceitar — a alternativa (progressive disclosure até preenchimento de preço-alvo) levou o Uniswap a ter ordens com expiração aplicada silenciosamente sem ciência do usuário. Em produto financeiro, campo crítico nunca pode ser hidden-default.

Chips de markup com duas linhas por chip: +36 px na seção de chips + custo de cálculo em tempo real do valor resultante para cada chip (3 valores computados a cada atualização do oracle). Custo de infra baixo (3 multiplicações simples); custo de layout médio.

Copy dinâmico de label: requer um estado de componente para o label do campo de preço-alvo. Implementação trivial (CSS + condição booleana), mas precisa de spec explícita para que não seja "otimizado" para label estático durante desenvolvimento.

i18n dos chips de markup: +5% mais caro em PT-BR precisa de equivalente em ES para outros locales LatAm. Template: +5% [token A] más caro; a estrutura do chip (percentual + texto + valor resultante) é internacionalizável sem redesign.

Aviso de allowance longa (1 ano): Tier 2 (não Tier 1) — escolha deliberada. Reversível (usuário pode cancelar a ordem), não é perda financeira irreversível. Se o produto evoluir para ordens não-canceláveis por design, reavaliar para Tier 1.

Visualizar Pool — Tela 06: On-ramp localizado BR/LatAm (Bottom Sheet)

1. Função da tela

Permite que o usuário compre cripto diretamente do contexto da pool — com moeda nominal = moeda de pagamento detectada por locale (BRL para Brasil), presets em valores típicos da moeda local, e orientação clara quando o token do par não é suportado diretamente pelo on-ramp. Foco: iniciante (principal) — quem chega aqui sem saldo suficiente para operar e precisa comprar antes.

2. Componentes / elementos

Estrutural

Chip-strip de saúde + mini-chip de identidade (≡ T04 e T05)

Mesmos componentes e regras — consistência cross-sheet do fluxo
Justificativa de manter o strip mesmo no on-ramp: usuário que chegou aqui via Comprar [TOKEN] (link de T04) deve saber que está comprando para operar nesta pool específica, não perdendo o contexto de por que está comprando

Seletor de token (herda do contexto da pool)

Token pré-selecionado: o token do par que o on-ramp suporta (ex: ETH, quando o par é WISE/ETH)
Nota contextual obrigatória, sempre visível abaixo do seletor:
- Quando token do par suportado (ETH): On-ramp disponível para ETH. Para WISE, compre ETH e use Fazer swap.
- Quando ambos suportados: sem nota — seletor funcional direto
- Quando nenhum suportado: nota substituída por estado de "sem cobertura" (ver Estados)
Nota não é tooltip — é texto visível. A distinção é deliberada: o usuário que precisou clicar em Comprar [TOKEN] provavelmente é iniciante; tooltip exige descoberta.

Campo de valor (moeda nominal = moeda do locale)

Label: Quanto você quer pagar?
Placeholder: R$ 0,00 (locale BR)
Presets em BRL ajustados ao equivalente aproximado em USD: R$ 100 · R$ 300 · R$ 1.000 · R$ 3.000
- Os presets não são valores fixos — são calculados a partir de $50 · $150 · $500 · $1.500 USD convertidos pelo FX rate atual + arredondamento para múltiplo de R$ 50
- Justificativa: presets fixos em BRL perdem relevância quando o real desvaloriza significativamente; presets baseados em equivalente USD mantêm consistência de poder de compra
Chip Outro ao final dos presets → abre input numérico livre com teclado numérico nativo
Eyebrow abaixo do campo: ≈ US$ XX · Taxa de câmbio: R$ X,XX/US$ · atualizado às HH:MM
Quando dado > 60s antigo: timestamp exibido em âmbar + (valor pode ter variado)

Comparativo de provedores (3 provedores default, expandível para mais)

Colunas: Você recebe · Taxa · Tempo
Você recebe: valor em token cripto (ex: 0,0287 ETH) + eyebrow em BRL (≈ R$ 945) — output em cripto como unidade central (usuário vai operar com ETH, não com BRL)
Provider pré-selecionado: Melhor cotação — o que dá mais ETH para o valor inserido
Badge de curadoria ao lado de cada provider: ✓ Verificado pela Kotai / Não verificado — curadoria declarada com fonte
Critério de "Melhor cotação" explícito: Provedor com maior quantidade de ETH recebida para R$ XXX
Provider selecionado exibe breakdown expandido inline: Taxas do provedor: R$ X,XX · Taxa de câmbio aplicada · Taxas de rede Kotai
Separação explícita das fontes de custo — não agrupa tudo em "taxa" opaca

Bloco de método de pagamento (abaixo do comparativo)

Para locale BR: PIX como método pré-selecionado (on-ramp local-first)
Estimativa de tempo: ~5 minutos via PIX
Nota de travamento de taxa: Taxa de câmbio travada por 15 minutos após confirmar
Para locales sem PIX (ex: MX): método local equivalente pré-selecionado (SPEI para México); fallback = Cartão

CTA dinâmico (fullwidth, sticky no rodapé)

Inserir valor — campo vazio
Continuar para pagamento via PIX — valor preenchido, provider selecionado
Continuar para pagamento via Cartão — quando cartão é método ativo
Ao tocar: abre fluxo do provider externo (novo contexto); retorno ao Kotai após conclusão com toast de resultado

Cosmético

Grab handle no topo do sheet
Expansor Ver mais provedores abaixo dos 3 provedores listados (scroll para mais)
Ícone de provider ao lado do nome (logo do parceiro)

3. Regras de negócio

Detecção de locale: IP + configuração de idioma do dispositivo → determina moeda nominal e método de pagamento padrão. Não é configuração do produto — é inferência de infra. Fallback: se locale desconhecido → USD + dropdown de seleção de moeda visível no topo do campo.

Presets dinâmicos: calculados em tempo de carregamento da tela a partir de equivalentes USD × FX rate atual + arredondamento. Fórmula: round(USD_equivalente × FX_rate / 50) × 50. Presets atualizam quando o FX rate muda além de ±3% em relação ao último cálculo (evita presets piscando a cada 30s).

Token pré-selecionado: lógica de seleção — (1) se o token B do par está na lista de suporte do on-ramp → pré-seleciona token B; (2) se não, tenta token A; (3) se nenhum → estado de "sem cobertura". A nota contextual segue a mesma lógica: só aparece quando há discrepância entre token do par e token suportado.

Aviso CEX: quando o token do par tem atributo listed_on_cex = true (ex: WISE, CAKE) mas não é suportado diretamente pelo on-ramp → a nota contextual inclui a orientação. O aviso não é exibido quando o usuário selecionou manualmente um token suportado (ETH, USDC) — evita aviso irrelevante no contexto ativo.

Provider selecionado persiste por sessão (não entre sessões): preferência aplicada enquanto o sheet estiver aberto. Ao fechar e reabrir, volta ao Melhor cotação. Justificativa: condições de mercado mudam entre sessões; a melhor cotação de 2h atrás pode não ser a melhor agora.

Taxa de câmbio travada por 15 min: conta regressiva começa ao tocar em Continuar para pagamento. Se o usuário retornar ao Kotai dentro de 15 min sem completar, a taxa pode ou não ter mudado — ao reabrir, fetch novo do FX rate e recalculo.

Eyebrow USD stale (> 60s): timestamp em âmbar + (valor pode ter variado). Dado não é removido — é sinalizado como possivelmente desatualizado. Aceitar a degradação com honestidade em vez de esconder o dado.

4. Estados não-triviais

Estado	Feedback visual	Recuperação
Vazio (campo)	Presets em BRL visíveis; provider "Melhor cotação" pré-selecionado sem valor; CTA `Inserir valor` disabled	—
Loading de cotações	Spinner em cada linha de provider + `Buscando melhores taxas...`	Presets de valor já visíveis para digitação antecipada enquanto cotações carregam
Token do par não suportado	Nota contextual visível: `On-ramp disponível para ETH. Para WISE, compre ETH e use Fazer swap.`; seletor mostra ETH pré-selecionado	Usuário pode mudar o token manualmente no seletor
Nenhum token do par suportado	Estado de sem-cobertura: `No momento o on-ramp não cobre os tokens deste par. Veja provedores alternativos.` + link para CEX recomendado	Link para CEX BR (ex: Mercado Bitcoin, Coinbase BR) como fallback — problema de ecossistema, não de UI
FX rate stale (> 60s)	Timestamp do eyebrow em âmbar + `(valor pode ter variado)`	Atualiza automaticamente quando oracle responde; o campo de valor mantém o que o usuário digitou
Sem provider disponível	`No momento não há provedores disponíveis. Tente novamente mais tarde.` + botão `Atualizar`	Não fecha o sheet; mantém o valor digitado
Locale desconhecido / fallback	USD como nominal + dropdown `Selecione sua moeda:` visível abaixo do campo	Dropdown seleciona moeda → presets recalculam na moeda escolhida
Retorno do provider (sucesso)	Sheet fecha; toast: `Compra confirmada · +X ETH chegará em ~5 min · ver transação`	T01 do fluxo recarrega para refletir novo saldo
Retorno do provider (falha/abandono)	Toast: `Pagamento não concluído. Tente novamente.`; sheet reabre no estado anterior	Valor digitado e provider selecionado preservados
Rede errada	Banner sticky `Mude para [Rede] para usar esta pool`; CTAs desabilitados	Orientação de troca de rede
Timeout da taxa travada (> 15 min)	Nota inline: `Taxa de câmbio expirou. Atualizando...` + refetch automático	Novo valor exibido com timestamp atualizado antes de liberar o CTA

5. Microcopy crítico (PT-BR)

CTAs dinâmicos

Inserir valor
Continuar para pagamento via PIX
Continuar para pagamento via Cartão
Atualizar (botão de retry no estado sem provider)

Notas e avisos contextuais

Token do par não suportado: On-ramp disponível para ETH. Para WISE, compre ETH e use Fazer swap.
Nenhum token suportado: No momento o on-ramp não cobre os tokens deste par. Veja provedores alternativos.
Critério de "Melhor cotação": Provedor com maior quantidade de ETH recebida para R$ XXX
Provider verificado: ✓ Verificado pela Kotai
Provider não verificado: Não verificado

Labels e eyebrows

Campo de valor: Quanto você quer pagar?
Taxa de câmbio atual: Taxa de câmbio: R$ X,XX/US$ · atualizado às HH:MM
Taxa de câmbio stale: Taxa de câmbio: R$ X,XX/US$ · atualizado às HH:MM (valor pode ter variado)
Travamento de taxa: Taxa de câmbio travada por 15 minutos após confirmar
Tempo estimado via PIX: ~5 minutos via PIX

Mensagens de erro e estado

Sem provider: No momento não há provedores disponíveis. Tente novamente mais tarde.
Locale desconhecido: Mostrando em dólar. Selecione sua moeda:
Timeout de taxa: Taxa de câmbio expirou. Atualizando...
Rede errada: Mude para [Rede] para usar esta pool

Toasts

Sucesso: Compra confirmada · +X ETH chegará em ~5 min · ver transação
Falha/abandono: Pagamento não concluído. Tente novamente.

6. Rastreabilidade obrigatória

🟢 Herdado

Comparativo de provedores com output em cripto como unidade central — usuário decide pela quantidade de token que vai receber, não pela taxa abstrata; herança do padrão Pancake: [pancake-final § Insight 5 — Transparência proativa antes do CTA; breakdown "Provider Fees / Pancake Fees"]
Provider pré-selecionado por critério declarado explicitamente ("Melhor cotação = maior quantidade de cripto recebida"): [pancake-final § Insight 1 — Defaults pró-iniciante sem pedir permissão; "Melhor cotação" pré-selecionado com critério explícito"]
Breakdown separado de taxas por fonte (taxas do provedor / taxa de câmbio / taxas de rede Kotai) — sem agregar tudo em "taxa" opaca: [pancake-final § Insight 5 — Transparência proativa; "breakdown sem esconder taxa da plataforma no spread"]
PIX como método default para locale BR — on-ramp local-first para target BR/LatAm: [pancake-final § Pilar 7 — Mobile-first interaction + Localização BR/LatAm como infraestrutura]

🔴 Corrige

USD como nominal universal independentemente do locale — corrigido pela moeda nominal = moeda de pagamento detectada por locale (BRL para Brasil): [uniswap-consolidado visualizar-pool § Oportunidade 8 — Localização sistêmica do on-ramp; "usuário brasileiro vê US$ no input e paga R$ no PIX sem transparência"]
Token default = ETH sem orientar que WISE não é suportado (quebra do princípio "herdar contexto" estabelecido em T01): corrigido pela nota contextual sempre visível que explica o caminho correto: [uniswap-consolidado visualizar-pool § Ponto isolado — Fricção Tela 11 — "token default ETH ignora herança de contexto"]
Aviso CEX sobre token específico propagado globalmente para toda a tela (irrelevante quando o usuário já selecionou um token suportado): corrigido pela exibição do aviso apenas quando o token selecionado tem o atributo listed_on_cex = true E não é suportado diretamente: [uniswap-consolidado visualizar-pool § Ponto isolado — Fricção Tela 11 — "aviso CEX persiste em contexto incorreto"]

🟡 Captura

Moeda nominal = moeda de pagamento detectada por locale (BRL para BR, MXN para MX, fallback USD) — nenhum concorrente implementa localização de nominal além de USD; hipótese: iniciante BR decide o aporte na moeda que conhece sem precisar fazer conversão mental; reduz abandono pré-conversão que é a maior causa de desistência em on-ramps cripto na região: [uniswap-consolidado visualizar-pool § Oportunidade 8 — Localização sistêmica do on-ramp]

⚪ Novo

Presets dinâmicos baseados em equivalente USD (não valores fixos em BRL): os relatórios descrevem a localização de moeda nominal mas não o mecanismo de ajuste de presets. Justificativa: presets fixos em BRL (R$ 100 / R$ 300 / R$ 1.000) perdem relevância de poder de compra quando o real desvaloriza significativamente — R$ 100 em 2021 era ~US$ 20; em 2024, ~US$ 18. Presets baseados em equivalentes USD ($50 · $150 · $500 · $1.500) com arredondamento garantem que os presets sempre reflitam valores típicos de aporte em DeFi. Custo: cálculo dinâmico + critério de atualização dos presets (só quando FX muda ± 3% para evitar presets piscando). Validação futura: medir taxa de seleção de preset vs input livre; se input livre dominar, presets foram mal calibrados.
Travamento de taxa de câmbio por 15 minutos após Continuar: sem precedente nos relatórios analisados. Justificativa: usuário que vê R$ 502 e recebe cobrança de R$ 527 pela variação do FX durante o fluxo do provider externo perde confiança e reclama (esse padrão é bem documentado em produtos de exchange fiat). 15 minutos é convenção de exchanges fiat (B2C) — não DEX, mas importável. Custo: coordenação com o provider externo para honrar a taxa travada; se o provider não suportar rate-lock, exibir o aviso como "taxa estimada" com disclaimer de variação. Validação: reclamações de discrepância de valor pós-confirmação nos primeiros 3 meses de operação.

7. Trade-offs e segunda ordem

FX rate feed por locale: custo de infra para BRL/USD, MXN/USD, COP/USD, ARS/USD etc. + SLA de atualização (60s com sinalização de staleness). Começar apenas com BRL no MVP; MXN e outros locales no segundo release.

Presets dinâmicos: cálculo de FX em tempo real a cada carregamento + critério de re-cálculo (± 3% de variação). Stale de 3% pode criar preset que arredonda para R$ 100 enquanto o correto seria R$ 110 — aceitar a margem de arredondamento como UX aceitável (não promete exatidão).

Lista de tokens suportados por on-ramp: curadoria manual + atualização frequente (providers adicionam/removem suporte de tokens sem prévio aviso). Custo operacional contínuo — requer processo de sync com providers parceiros no mínimo semanal.

Nota contextual de token não suportado: orienta o caminho correto (ETH → swap) mas não elimina a fricção de 2 passos. É um problema de ecossistema (A6 — on-ramp ainda não suporta todos os tokens de DEX) — não tentar resolver inline além da orientação. O caminho de 2 passos precisa ser fluido: ao concluir a compra de ETH, toast de sucesso oferece Usar ETH para fazer swap para WISE → como CTA acessório.

Retorno do provider externo: fluxo de on-ramp abre o provider em contexto externo (webview ou browser). Retorno pode falhar (usuário fecha o app, perde a internet) — o estado de "retorno com falha" deve ser detectável via polling da carteira por novos créditos por até 30 min após o início do fluxo. Se detectar o crédito mesmo sem retorno explícito do provider, exibir toast de sucesso.

i18n: presets, método de pagamento e microcopy de tempo estimado (~5 minutos via PIX) precisam de variantes por locale. Template: ~[N] minutos via [MÉTODO] — internacionalizável. Maior custo: mapeamento de métodos por país (PIX → BR, SPEI → MX, PSE → CO, etc.) e tempos estimados distintos por método.

Adicionar Liquidez — Tela 01: Entrada — Descoberta e Seleção de Par e Modo

1. Função da tela

Tela de entrada do fluxo "Adicionar Liquidez" para o usuário sem pool pré-selecionado: converte a intenção vaga de "quero ganhar rendimento" em seleção de par e modo de provisão, com o sistema recomendando o protocolo adequado ao par — invertendo a ordem imposta por Uniswap e PancakeSwap, que exigem protocolo antes do par. Foco: iniciante BR/LatAm sem experiência prévia em LP.

2. Componentes / Elementos

Estruturais (definem o paradigma da tela)

a) Stepper horizontal de progresso Três passos visíveis desde a entrada: "Par e modo" (ativo) | "Configurar" | "Confirmar". Label do passo "Configurar" muda conforme modo escolhido: "Configurar faixa" (Concentrada) ou "Definir valores" (Simples). Entrega contrato visual: este processo tem etapas conhecidas.

b) Seletor de par — dois campos de token em sequência Campo Token A aparece primeiro; Token B só ativa após Token A selecionado. Busca por símbolo, nome ou endereço de contrato. Chips de sugestão em três camadas: recentes do usuário → trending na rede ativa → populares global. Sem seletor de protocolo visível neste passo — protocolo é consequência, não pré-requisito.

c) Card de saúde do pool (aparece após ambos os tokens definidos) Exibe: TVL + Volume 24h + APR estimado + badge de atividade (● Ativo / ⚠ Baixa atividade / ● Inativo). Estado colapsado ("Ver detalhes ▾") em pool saudável; expandido forçado quando Vol/TVL < 0,001. Se o par tem múltiplos pools (V3 0,05% + V3 0,3%): card agrega métricas cross-fee com sub-item "Ver N pools disponíveis ▾".

d) Cards de modo de provisão (aparecem após par definido) Máximo três modos relevantes ao par, renderizados como cards verticais side-by-side. Cada card: label primário em benefício do usuário + label secondary com nome técnico discreto + 1 frase de diferencial. Card recomendado pelo sistema exibe badge "Recomendado para este par". Até 3 modos disponíveis:

Label primário	Secondary técnico	Diferencial
Simples e passiva	Liquidez V2	Depositar e não gerenciar — rendimento automático
Concentrada em um intervalo	Liquidez V3/V4	Mais eficiente: exige ajuste da faixa quando o preço mudar
Par correlacionado	StableSwap	Para pares como USDC/USDT: menos perda por variação de preço

e) Aviso inline de par incompatível com modo (condicional) Aparece quando usuário seleciona manualmente modo Correlacionado para par volátil. Banner amarelo abaixo dos cards, não modal. Dois CTAs de saída: "→ Usar Concentrada" (primário) e "Continuar assim mesmo (risco entendido)" (laranja).

f) CTA principal Label dinâmico refletindo o próximo obstáculo específico. Disabled até par válido + modo selecionado.

g) Seção de discovery — "Populares agora" (cosmético funcional) 3–5 cards de pools com indicadores rápidos: par + APR estimado + badge de atividade. Em desktop: coluna lateral. Em mobile: carrossel horizontal abaixo dos seletores. Visível antes de o usuário selecionar tokens — scaffolding de intenção para quem chegou sem par em mente.

Cosméticos

Breadcrumb: "Ganhar rendimento / Adicionar liquidez"
Ícone combinado de par (sobreposição dos dois ícones de token) no card de saúde
Chip "Novo" em pools lançadas nas últimas 72h na seção discovery
Timestamp "Preço atual: R$ XX,XX · Atualizado há N min" abaixo do seletor de par

3. Regras de Negócio

Seleção de par: Token A ≠ Token B. Import por endereço de contrato dispara preview obrigatório on-chain (nome resolvido + supply + idade do contrato + holders) e banner de token não verificado. Resolução on-chain obrigatória antes de exibir o token importado.

Recomendação de modo por heurística de par:

Par correlacionado (stables, LST/ETH, WBTC/BTC): recomenda "Par correlacionado"
Par de alta liquidez com histórico de volume (ETH/USDC, BNB/USDT): recomenda "Concentrada"
Par com liquidez baixa ou par novo no acervo: recomenda "Simples" (mais seguro sem gestão de range)
Se não há pool para este par: estado especial (ver Estados)

Validação de compatibilidade modo↔par: Se usuário seleciona modo Correlacionado para par volátil (detectado por heurística): banner amarelo inline com ação explícita requerida antes de avançar. Não bloqueia silenciosamente.

Routing condicional ao avançar:

Par válido + pool existe + modo Concentrada → avança para adicionar-liquidez-02
Par válido + pool existe + modo Simples → avança para adicionar-liquidez-03
Par válido + pool não existe → estado especial: routing para criar-pool/criar-pool-01 (não continua este fluxo)

CTA dinâmico: Sequência de label obrigatória: "Selecionar tokens" (estado vazio) → "Selecionar modo" (par definido, modo pendente) → "Configurar aporte" (pronto para avançar).

Discovery section: Carregamento lazy — não bloqueia render principal dos seletores. TTL de cache: 5 min. Falha silenciosa (section não renderiza se API demorar > 3s).

4. Estados Não-Triviais

Vazio (entry sem contexto): Par não definido. Seletores com placeholder "Escolha um token". Cards de modo e pool health não visíveis. Discovery section ativa. CTA "Selecionar tokens" disabled.

Loading de dados do pool: Após seleção de Token B: skeleton animation no card de saúde. Se > 5s sem resposta: mensagem "Buscando dados do pool... pode levar alguns segundos." Fallback parcial com dado cached se disponível.

Pool não existe para o par: Card de saúde exibe estado especial: badge âmbar "Pool ainda não existe para este par". Mensagem: "Você seria o primeiro provedor de liquidez — e definiria o preço inicial de troca." Aviso: "Criar um pool é uma operação avançada." Cards de modo ocultados. CTA muda para "Criar pool →" (secundário, não verde). Clique redireciona para criar-pool-01 preservando o par selecionado como parâmetro.

Par com token não verificado: Banner amarelo após import por endereço: "⚠ Token não verificado — qualquer pessoa pode criar um token com qualquer nome. Verifique o endereço com cuidado antes de continuar." Preview: nome resolvido + supply total + data de deploy. CTA "Adicionar assim mesmo" (laranja) + "Cancelar" (primário de escape).

Pool inativa (Vol/TVL < 0,001): Card de saúde expandido forçado com badge vermelho "Pool inativa". Mensagem: "Este pool tem pouca atividade — o rendimento de taxas pode ser próximo de zero. Considere explorar outros pares." CTA avança mas com label "Adicionar mesmo assim" (laranja, não verde).

Modo incompatível selecionado manualmente: Banner amarelo inline abaixo dos cards. Não modal. Dois CTAs: "→ Usar modo Concentrada" (primário) e "Continuar com risco entendido" (laranja). O banner não desaparece automaticamente — requer ação explícita do usuário.

Erro de rede / RPC lento: Card de saúde exibe "Não foi possível carregar dados do pool. [Tentar novamente]". Seleção de par permanece intacta. Avançar com dados não carregados: desabilitado até retry com sucesso ou timeout de 10s (neste caso exibe dado parcial com nota "Dados podem estar desatualizados").

5. Microcopy Crítico

Título da tela: "Fornecer liquidez"

Sub-headline abaixo do título: "Adicione tokens a um pool e ganhe rendimento em cada negociação realizada neste par."

Placeholder campo token: "Escolha um token"

Label modo Simples:

Simples e passiva Liquidez V2 · Depositar e não gerenciar "Ideal para quem quer ganhar rendimento sem precisar acompanhar o mercado."

Label modo Concentrada:

Concentrada em um intervalo Liquidez V3/V4 · Exige gestão da faixa de preço "Mais eficiente: o mesmo capital rende mais — mas você precisa ajustar a faixa quando o preço mudar."

Label modo Correlacionado:

Par correlacionado StableSwap · Otimizado para ativos de preço próximo "Para pares como USDC/USDT ou stETH/ETH: menos Impermanent Loss, mais eficiência."

Badge recomendação: "Recomendado para este par ✓"

Warning par incompatível (banner inline):

"⚠ [Token A] e [Token B] não são ativos correlacionados — este modo é otimizado para pares como USDC/USDT. Continuar pode resultar em perdas maiores por variação de preço." [→ Usar modo Concentrada] [Continuar com risco entendido]

Card pool não existe:

"Pool ainda não existe para [Token A]/[Token B] nesta rede." "Você seria o primeiro provedor de liquidez e definiria o preço inicial." [Criar pool →]

Card pool inativa:

"⚠ Pool com pouca atividade · Vol/TVL < 0,1% · O rendimento de taxas pode ser próximo de zero"

Token não verificado:

"⚠ Token não verificado — qualquer pessoa pode criar um token com qualquer nome. Verifique o endereço com cuidado antes de continuar." [Adicionar assim mesmo] [Cancelar]

CTA sequência: "Selecionar tokens" → "Selecionar modo" → "Configurar aporte"

Header da seção discovery: "Populares agora em [rede ativa]"

Nota na seção discovery: "Pools com maior atividade nas últimas 24h."

6. Rastreabilidade Obrigatória

🟢 Herdado

Chips de sugestão em camadas (recentes → trending rede → trending global): Defaults em 4 camadas estabelecidos como princípio — [uniswap-final § Fricção 4 — Defaults ignoram contexto que o sistema já tem] (o oposto: aqui aplicamos o padrão correto de defaults contextuais)
Card de saúde do pool com estado colapsado/expandido forçado em inativo: [uniswap-nova-posicao.md § Oportunidade 2 — Card de pré-visualização do pool destino antes do depósito]; padrão de comportamento colapsado/expandido herdado de criar-pool-01 (design system Kotai)
Stepper com labels dinâmicos conforme modo: [uniswap-nova-posicao.md § Insight 1 — Stepper pedagógico e contextual]
CTA dinâmico com label do próximo obstáculo específico: [pancake-final § Insight — Transparência proativa antes do CTA]
Progressive disclosure (mode cards + health card só após par definido): [uniswap-final § Insight — Progressive disclosure como padrão arquitetural, não recurso pontual]
Ícone de par combinado no card: convenção válida de reconhecimento cross-DEX — [uniswap-final § herdável — Múltiplas representações do mesmo dado]

🔴 Corrige

Cards de modo por benefício (não protocolo): corrige [pancake-final § Fricção 1 — Léxico de protocolo como vocabulário primário de UI] (universal — 9 fluxos) e [uniswap-nova-posicao.md § Fricção 1 — Versão como caixa-preta técnica sem pedagogia]
Par primeiro, protocolo recomendado depois: corrige [pancake-adicionar-liquidez.md § Fricção Estrutural 1 — Seleção de protocolo como caixa-preta técnica sem pedagogia]
Warning inline de par incompatível (não bloqueio silencioso): corrige [pancake-adicionar-liquidez.md § Ponto isolado, tela 4 — form aceita BNB+CAKE em StableSwap sem validação]
Token import com preview on-chain antes de exibir: corrige [pancake-final § Fricção 5 — Risk signaling ausente em pontos de decisão]
Labels de modo e microcopy inteiramente em PT-BR: corrige [pancake-adicionar-liquidez.md § Fricção Sistêmica — Localização incompleta: inglês técnico dentro de UI PT-BR]
Estado especial "pool não existe" com routing explícito para Criar Pool: corrige [uniswap-nova-posicao.md § Observações adicionais — Caso 'pool ainda não existe' sem UX dedicada]

🟡 Captura

Inversão de fluxo — par primeiro → protocolo recomendado (Path B): [pancake-adicionar-liquidez.md § Oportunidade 1 — Entrada por intenção: protocolo recomendado por par, não escolhido como pré-requisito] + [uniswap-nova-posicao.md § Oportunidade 1 — Pedagogia de versão: do dropdown técnico à assistência baseada em perfil]. Path B adotado: recomendação contextual com override explícito, não imposição. Hipótese: iniciante que recebe "Recomendado para BNB/USDT: Concentrada" tem menor taxa de modo incompatível vs. iniciante que escolhe protocolo às cegas.
Card de saúde do pool antes do aporte: [uniswap-nova-posicao.md § Oportunidade 2 — Card de pré-visualização do pool destino antes do depósito]. Hipótese: usuário que vê "APR 0,00% · Vol/TVL <0,1%" antes de confirmar não aporta em pool morto.

⚪ Novo

Heurística de recomendação de modo por tipo de par (correlacionado / alta-liquidez / baixa-liquidez): sem precedente direto nos consolidados como regra de negócio codificada. Justificativa: o Path B da Oportunidade 1 (pancake-adicionar-liquidez.md) exige a heurística para funcionar — sem ela, "recomendação" é aleatória e prejudica mais do que ajuda. Custo: lógica de classificação de par mantida pela equipe de produto com atualização por release. Evidência a coletar: taxa de aceitação da recomendação vs. troca manual de modo; taxa de perdas em posições de modo incompatível antes/depois.
Discovery section "Populares agora": sem precedente direto nos consolidados de Adicionar Liquidez. Justificativa: o iniciante que não tem par em mente precisa de scaffolding de discovery; sem ele, abandona a tela sem ação. A section tem custo de render (lazy loading) e cache (TTL 5 min). Evidência a coletar: CTR para pools da section vs. taxa de abandono sem section.
CTA "Criar pool →" como estado condicional dentro do card de saúde: sem precedente nos consolidados. Justificativa: evita que o usuário percorra o formulário de configuração inteiro para descobrir no final que o pool não existe. Custo: lógica de routing condicional na T01 + handoff de par selecionado como parâmetro para criar-pool-01.

7. Trade-offs e Segunda Ordem

Heurística de par↔modo: Se a classificação estiver errada (ex: tratar ETH/WBTC como "não correlacionado" em ciclos onde eles se movem juntos), o badge "Recomendado" amplifica o erro em vez de mitigá-lo. Mitigação: threshold conservador de correlação; "Continuar assim mesmo" sempre disponível; heurística revisada por release após dados de aceitação. Custo de manutenção contínuo.

Discovery section: Aumenta payload da tela. Em mobile com conexão lenta, o carrossel pode aparecer depois dos controles principais — prioridade de render: seletor de par > pool health card > discovery. Falha silenciosa da section não quebra o fluxo principal.

State "pool não existe" dentro de Adicionar Liquidez: Cria bifurcação de produto (Adicionar Liquidez vs. Criar Pool) que pode confundir usuário que não entende a diferença. Mitigação: copy claro "Você seria o primeiro provedor" + routing explícito para Criar Pool (não um redirect silencioso). O handoff de parâmetros (par selecionado) entre os dois fluxos é obrigatório para não forçar o usuário a re-selecionar tokens no Criar Pool.

Cognitive load do T01: Stepper + par + health card + mode cards + discovery = mais superfície que o seletor de token padrão. Risco: parecer denso para o iniciante. Mitigação: disclosure progressivo rigoroso — health card e mode cards só aparecem após par definido; discovery é menor prioridade visual; texto é escasso nas cards de modo (1 frase cada).

i18n: 3 modos × 3 strings cada (label, secondary, descrição) = 9 strings adicionais por idioma. Custo de manutenção real quando novos modos/protocolos forem adicionados. Mitigação: componente de card de modo com props de conteúdo (não hardcoded por tela).

Adicionar Liquidez — Tela 02: Configurar Aporte — Posição Concentrada

1. Função da tela

Tela de configuração para adição de liquidez no modo Concentrada (V3/V4) em um pool existente: o usuário define a faixa de preço e os valores de aporte, com contexto do pool sempre visível e presets probabilísticos calibrados ao histórico do par. Foco: intermediário que aceita gerir sua faixa em troca de maior eficiência de capital; iniciante protegido pelos presets e pelo card de saúde forçadamente expandido quando o pool está problemático.

2. Componentes / Elementos

Estruturais

a) Mini-card de identidade do pool (sticky no topo) Par + fee tier + badge de atividade + Vol 24h compact + APR compact. Em mobile: chip de identidade colapsável por tap com drawer de saúde completo. Nunca removido durante a configuração — garante que o usuário sabe onde está aportando em todo momento. Se pool inativo: mini-card expandido forçado com banner vermelho (sem colapso disponível).

b) Stepper horizontal "Par e modo" (✓ completo) | "Configurar" (ativo, passo atual) | "Confirmar". Clique em "Par e modo" retorna para T01 preservando dados de configuração (não destrói o formulário). Clique em "Confirmar" desabilitado até formulário válido.

c) Seletor de fee tier (segmented control) Exibe os pools reais existentes para este par, com fee tier e percentual de volume de cada um. Exemplo: "0,05% · 72% do volume" | "0,3% · 25% do volume" | "1% · 3% do volume". A opção com maior % de volume recebe badge "Mais usado". Para par com fee tier único: componente colapsado com nota "(Apenas um pool disponível para este par — fee XX%)" sem forçar interação onde não há decisão real.

d) Configurador de faixa de preço Três presets horizontais calibrados ao histórico deste pool específico + opção "Personalizado":

"Conservador · ~85% do tempo in-range"
"Equilibrado · ~70% do tempo in-range" (selecionado por default)
"Agressivo · ~45% do tempo in-range"

Mini-chart de distribuição de liquidez inline: mostra onde a liquidez atual está concentrada no pool, com banda destacada para a faixa configurada. Campos "Mín" e "Máx" editáveis. Auto-flip de cotação quando preço do par < 0,001 (ex: SHIB/USDC: exibe USDC/SHIB automaticamente com indicador "Mostrando [Token B]/[Token A] ↕ Trocar").

e) Campos de aporte com acoplamento bidirecional Ao inserir Token A: Token B calcula-se automaticamente pela proporção da faixa vs. preço atual. Se faixa 100% acima ou abaixo do preço: apenas 1 campo ativo, o outro exibe "—" com tooltip explicativo. Preset chips de saldo (25% / 50% / 75% / Tudo) com affordance honesta: outline quando saldo = 0, tap abre prompt de compra contextual. Equivalente em R$ abaixo de cada campo (Pilar 5 — locale BR).

f) Card de custo agregado (aparece após ambos os campos preenchidos)

Total a depositar:   R$ X.XXX,XX
Gas estimado:        ~R$    XX,XX
──────────────────────────────────
Você paga agora:     R$ X.XXX,XX

Sub-label: "O total depositado permanece seu na posição — o gas é o custo para registrar na rede."

g) Slippage adaptativo Chip "Auto (X%)" com valor calculado visível. Não é "Auto" opaco — exibe o percentual atual para auditoria. Tooltip expandindo critério: "Calculado com base na profundidade deste pool e na volatilidade recente do par. Para este par: X%." Aviso inline quando Auto > 2%: "⚠ Slippage acima de 2% — pool com liquidez baixa ou alta volatilidade recente. Verifique antes de continuar." Botão "Configurar →" para override manual.

h) CTA principal Label dinâmico. Disabled até faixa válida + ambos os valores preenchidos + saldo suficiente.

Cosméticos

Indicador de participação: "Seu aporte representa ~X% da liquidez total do pool" (calculado client-side após valores inseridos)
Ícone de câmbio (flip ↕) junto ao campo de preço para flip manual além do auto-flip
Timestamp "Preço atual: R$ X.XXX,XX · Atualizado há N min" abaixo do configurador de faixa

3. Regras de Negócio

Faixa de preço:

Min < Max obrigatório. Min == Max: warn imediato "A faixa mínima é um ponto — a posição nunca ficará in-range."
Faixa 100% acima do preço atual: warn "Faixa acima do preço — você aportará 100% em [Token A]. Você ganhará taxas quando o preço subir até esta faixa." Continuar permitido.
Faixa 100% abaixo do preço atual: warn simétrico para Token B. Continuar permitido.
Auto-flip de cotação: threshold 0,001 (padrão estabelecido no design system Kotai).

Acoplamento dos campos de aporte: Ao inserir Token A: Token B = valor de A × razão de token B pela posição na faixa definida. Se posição 100% single token (faixa fora do preço): campo do token ausente bloqueado e exibe "—" com tooltip "Nenhuma quantidade de [Token B] é necessária nesta faixa de preço."

Saldo insuficiente: CTA vira "Saldo insuficiente em [Token A] · Comprar [Token A] →" (laranja). Não bloqueia silenciosamente — nomeia o token específico em falta + link direto para on-ramp/compra contextual.

Aprovações de token: Se aprovação necessária para um ou ambos os tokens: sub-label no CTA "(Aprovação necessária)". Ao avançar: aprovação tratada como passo proativo do fluxo (seguindo padrão de criar-pool-04 estabelecido no design system) — não como erro de recuperação.

Fee tier único: Componente de seletor colapsado, não forçando interação. Segue o princípio do consolidado Pancake: filtro de 1 item não exerce função de filtro — não forçar o custo cognitivo sem entregar escolha real.

Dados históricos insuficientes para presets: Pools com < 30 dias de histórico ou dados de oráculo insuficientes: presets substituídos por nota "Dados históricos insuficientes para este pool. Defina a faixa manualmente ou use ±10% como ponto de partida." Presets de probabilidade ocultados neste caso.

Pool inativa detectada ao entrar nesta tela: Mini-card expande forçado com banner vermelho. CTA disponível mas com label "Adicionar mesmo assim" (laranja) com delay de 1,5s antes de habilitar (sinal de ação consciente, sem ser type-to-confirm completo — calibrado pela severidade da situação).

4. Estados Não-Triviais

Vazio (chegou da T01 sem valores preenchidos): Preset "Equilibrado" pré-selecionado (default do caso 90%). Campos de aporte com placeholder. CTA "Inserir valores" disabled. Slippage "Auto (calculando...)" com skeleton até dado do pool carregado.

Loading de dados do pool: Skeleton no mini-card, no seletor de fee tier e nos presets de probabilidade histórica. Timeout de 3s: mensagem "Buscando dados do pool... pode levar alguns segundos."

Dados de preço stale (oráculo lento ou offline): Badge âmbar no timestamp: "Dados de 5+ min atrás — o preço pode ter mudado. [Atualizar]". Slippage automático aumenta como proteção (valor aumentado com nota "Aumentado por precaução — dados do pool estão desatualizados").

Pool inativa: Mini-card expandido forçado, banner vermelho "Pool inativa". CTA "Adicionar mesmo assim" (laranja, delay 1,5s). Preset "Equilibrado" mantido, mas com nota "Atenção: pool com baixa atividade."

Faixa fora do preço atual: Banner amarelo inline abaixo do configurador: "Faixa [acima/abaixo] do preço atual — você aportará 100% em [Token]. Isso é válido; você ganhará taxas quando o preço entrar nesta faixa." Campo do token ausente: bloqueado, exibe "—".

Saldo insuficiente: CTA laranja com label específico: "Saldo insuficiente em [Token A] · Comprar [Token A] →". Sub-label abaixo: "Você tem R$ XX,XX · Necessário: R$ YY,YY."

Presets indisponíveis (pool nova ou dados insuficientes): Área de presets substituída por texto e sugestão de ponto de partida manual (±10%). Design da área preservado para consistência visual.

Sucesso / avanço: Stepper marca T02 como ✓. Transição para tela de revisão e confirmação (próxima etapa do fluxo, não neste lote). Toast de contexto na tela de confirmação: "Posição Concentrada configurada · [Token A]/[Token B] · Faixa: R$ XX – R$ YY."

5. Microcopy Crítico

Mini-card de identidade:

"Você está adicionando em: [USDC/ETH] · 0,05% · ● Ativo"

Seletor de fee tier — label:

"Pools disponíveis para este par"

Fee tier com badge:

"0,05% · 72% do volume · Mais usado ✓" "0,3% · 25% do volume" "1% · 3% do volume"

Pool fee tier único:

"(Apenas um pool disponível para este par — fee 0,3%)"

Configurador de faixa — label:

"Faixa de preço" "Você ganha taxas quando o preço do par estiver dentro desta faixa."

Presets:

"Conservador · ~85% do tempo in-range" "Equilibrado · ~70% do tempo in-range" "Agressivo · ~45% do tempo in-range" "Personalizado"

Warning faixa acima do preço:

"⚠ Faixa acima do preço atual — você aportará 100% em [Token A]. Você ganhará taxas quando o preço subir até esta faixa."

Warning faixa abaixo do preço:

"⚠ Faixa abaixo do preço atual — você aportará 100% em [Token B]. Você ganhará taxas quando o preço cair até esta faixa."

Card de custo:

"Total a depositar: R$ X.XXX,XX" "Gas estimado: ~R$ XX,XX" "Você paga agora: R$ X.XXX,XX" "O total depositado permanece seu na posição — o gas é o custo para registrar na rede."

Slippage chip:

"Auto (1,2%)"

Tooltip slippage:

"Calculado com base na profundidade deste pool e na volatilidade recente do par. Para este par: 1,2%. Para ajustar: [Configurar →]"

Warning slippage alto:

"⚠ Slippage automático acima de 2% — este pool tem liquidez baixa ou alta volatilidade recente. Verifique antes de continuar."

Auto-flip indicador:

"Mostrando [Token B]/[Token A] ↕ Trocar"

CTA sequência:

"Inserir valores" → "Definir faixa" → "Revisar aporte"

Saldo insuficiente:

"Saldo insuficiente em [Token A] · Comprar [Token A] →"

Pool inativa — CTA:

"Adicionar mesmo assim"

Indicador de participação:

"Seu aporte representa ~X% da liquidez total do pool"

6. Rastreabilidade Obrigatória

🟢 Herdado

Stepper com label dinâmico por modo: [uniswap-nova-posicao.md § Insight 1 — Stepper pedagógico e contextual]
Mini-card de identidade sticky (nunca removido durante ação contextualizada): padrão estabelecido em visualizar-pool-04 e visualizar-posicao-02 no design system Kotai; princípio base: [uniswap-final § Insight — Progressive disclosure como padrão arquitetural]
Preset chips de saldo com affordance honesta (outline em saldo = 0): padrão estabelecido em visualizar-pool-03 do design system Kotai
Equivalente R$ em ambos os campos de aporte: [uniswap-final § Insight — Múltiplas representações do mesmo dado + bidirecionalidade]
CTA dinâmico com label do obstáculo específico ("Saldo insuficiente em [Token A] · Comprar [Token A] →"): [pancake-final § Insight — Transparência proativa antes do CTA]; padrão de CTA com label de obstáculo estabelecido em visualizar-pool-03 do design system Kotai
Linha-soma fechada "Total a depositar / Gas / Você paga agora": padrão estabelecido em criar-pool-03 do design system Kotai
Slippage Auto com valor visível para auditoria (não caixa-preta): [uniswap-nova-posicao.md § Ponto isolado — "Auto = 2,5%" sem critério exposto] — o problema identificado é que o valor existe mas o critério não é exposto; corrigimos expondo ambos
Auto-flip de cotação por threshold de magnitude (0,001): padrão estabelecido no design system Kotai
Pool inativa: CTA laranja (não verde) com delay para ação consciente: [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência] + princípio de CTAs destrutivos nunca como primário verde (Pilar 3 Kotai)

🔴 Corrige

Fee tier exibindo pools reais com % de volume (não apenas número técnico): corrige [pancake-adicionar-liquidez.md § Fricção 2 — Componente de filtro de pool: vocabulário intraduzível] (CLAMM/LBAMM como labels sem consequência) + [uniswap-nova-posicao.md § Fricção 3 — Affordance e semântica ambígua em campos de decisão financeira]
Fee tier único: componente colapsado sem forçar interação vazia: corrige [pancake-adicionar-liquidez.md § Fricção 2 — StableSwap filtro com item único "Classic" força interação sem choice real]
Slippage adaptativo ao pool específico com critério exposto: corrige [uniswap-nova-posicao.md § Oportunidade 3 / Ponto isolado — "Auto = 2,5%" sem critério; "Auto" semântico (sugere adaptação) vs. "Auto" estático (constante interna)]
Mini-card de identidade sticky — nunca perde contexto de qual pool está configurando: corrige [uniswap-nova-posicao.md § Fricção 2 — Ausência de estado do pool destino na janela de decisão de aporte]
Auto-flip de cotação por magnitude: corrige [pancake-final § Fricção 2 — i18n parcial e inconsistente] (confusão de denominação de preço em valores muito pequenos)
Presets históricos calibrados ao pool específico (não genérico): corrige [uniswap-nova-posicao.md § Fricção 1 — v4 como default expõe range concentrado sem ferramenta pedagógica para iniciante]

🟡 Captura

Slippage adaptativo ao pool específico: [uniswap-nova-posicao.md § Oportunidade 3 — Slippage adaptativo ao par/pool]. Hipótese: transações falham menos (slippage insuficiente em pool raso) e usuário não perde em pool saudável por slippage excessivo genérico.
Presets de faixa com probabilidade histórica deste pool específico: derivado de [uniswap-nova-posicao.md § Oportunidade 1 — Pedagogia de versão] (mesma filosofia de guiar o iniciante na decisão arquitetural mais importante). Hipótese: iniciante que escolhe preset "Equilibrado · ~70% do tempo in-range" tem posição in-range por mais tempo na primeira experiência, melhorando NPS de LP.
Fee tier como pools reais com % de volume roteado: [uniswap-pools.md § Fricção 2 — Fragmentação de pares compromete decisão de LP]. Hipótese: usuário que vê "0,05% · 72% do volume" não aporta no fee tier com zero roteamento — erro que atualmente não é sinalizado em nenhum DEX.

⚪ Novo

Fee tier exibindo % de volume cross-pool para o mesmo par: sem precedente nos consolidados como componente de configuração de LP. Justificativa: resolve dentro do formulário de configuração a Fricção 2 do Uniswap Pools (fragmentação de pares) — usuário vê instantaneamente qual fee tier atrai mais liquidez real sem precisar navegar para outra tela. Custo: chamada adicional de volume por fee tier; fallback gracioso quando dado indisponível (exibe fee sem % de volume). Evidência a coletar: taxa de seleção de fee tier "errado" (sem volume) antes/depois.
Indicador "Seu aporte representa ~X% da liquidez total do pool": sem precedente nos consolidados. Justificativa: orienta o intermediário que não sabe se seu aporte é significativo ou negligenciável — contexto que afeta decisão de range e fee tier. Custo: uma divisão client-side com dados já carregados; negligenciável. Evidência a coletar: correlação entre % de participação e taxa de abandono do formulário.
Delay de 1,5s no CTA de pool inativa antes de habilitar ("ação consciente sem type-to-confirm"): sem precedente nos consolidados. Justificativa: pool inativa é situação de risco moderado — não justifica type-to-confirm completo (Tier 1 da Pilar 3), mas o clique imediato num CTA laranja ainda pode ser acidental. O delay de 1,5s impõe latência mínima que sinaliza "esta ação requer consciência" sem bloquear o usuário avançado que entendeu o risco. Calibrado entre cosmético (sem delay) e Tier 1 (type-to-confirm completo). Custo: lógica de delay condicional por estado de pool — trivial de implementar. Evidência a coletar: taxa de aporte em pool inativa antes/depois do delay; taxa de abandono no estado pool inativa.

7. Trade-offs e Segunda Ordem

Presets com probabilidade histórica por pool: Exige série histórica de preço vs. range por pool. Para pools com < 30 dias de dados: fallback para sugestão manual sem percentuais — experiência degradada mas não quebrada. Custo de infra: cache de série histórica por pool com TTL configurável. Pools com alta volatilidade recente podem ter probabilidades históricas desatualizadas; timestamp de "calculado em [data]" mitiga parcialmente.

Fee tier como pools reais com % de volume: Exige chamada de volume por fee tier ao carregar a tela. Em pools com indexador lento (rede congestionada): fallback para fee tier sem % — componente degrada graciosamente para segmented control padrão. Custo: +1 chamada de API por carregamento de T02.

Mini-card sticky em mobile: Em viewport muito estreito (< 375px), mini-card sticky pode consumir 20–25% do espaço disponível. Mitigação: versão colapsável por tap em mobile (chevron de colapso/expansão) com estado mínimo sempre visível (par + badge atividade, 1 linha).

Slippage adaptativo em tempo real: Cálculo de profundidade de pool em tempo real gera latência. Mitigação: exibir estimativa baseada em dados cached imediatamente ("Auto (~X%)") e atualizar com dado preciso em segundo plano quando disponível.

Separação T02/T03 (Concentrada vs. Simples): Dois screens de configuração em vez de uma tela bifurcada aumenta superfície de manutenção. Vantagem: cada tela tem escopo claro, não carrega complexidade do outro modo. O stepper exibe o mesmo label "Configurar" para ambos os modos — consistência visual mantida. Routing T01→T02 ou T01→T03 deve ser transparente: o usuário não deve sentir que "mudou de tela", apenas que a configuração reflete o modo escolhido.

Adicionar Liquidez — Tela 03: Configurar Aporte — Posição Simples

1. Função da tela

Tela de configuração para adição de liquidez no modo Simples (V2 / StableSwap passivo) em um pool existente: o usuário define os valores de aporte sem precisar gerenciar intervalos de preço — o paradigma "depositar e não gerenciar". Foco: iniciante BR/LatAm que quer rendimento automático, protegido por validação inline de compatibilidade par↔protocolo e por pedagogia embutida no ponto de decisão, não em docs externos.

2. Componentes / Elementos

Estruturais

a) Mini-card de identidade do pool (sticky no topo) Par + badge de modo ("Simples e passiva · V2" ou "Par correlacionado · StableSwap") + badge de atividade + Vol 24h compact + APR estimado compact com asterisco. Mesmo padrão de T02 e do design system Kotai — nunca removido durante a configuração. Se pool inativo: expandido forçado com banner vermelho.

b) Stepper horizontal "Par e modo" (✓ completo) | "Configurar" (ativo) | "Confirmar". Clique em "Par e modo" retorna para T01 preservando contexto.

c) Campos de aporte com proporção fixa Token A e Token B. A proporção é fixada pelo protocolo (V2: fórmula constant product; StableSwap: proporcional ao pool). Ao inserir Token A: Token B calcula-se automaticamente. Campo de Token B exibe sub-label "(Calculado automaticamente com base no preço atual)" para comunicar o acoplamento. Campo de Token B não editável diretamente — se o usuário tentar focar nele, foco retorna para Token A com indicador visual sutil.

Preset chips de saldo (25% / 50% / 75% / Tudo) com affordance honesta: outline quando saldo = 0, tap abre prompt de compra contextual. Equivalente em R$ obrigatório abaixo de cada campo.

d) Aviso de par incompatível com modo (condicional — StableSwap) Aparece quando par selecionado não é correlacionado (ex: BTC/ETH em modo StableSwap). Banner amarelo inline com dois CTAs explícitos. Não bloqueia silenciosamente — o usuário precisa tomar uma ação consciente antes de avançar.

e) APR estimado com caveat obrigatório Exibido abaixo dos campos de aporte, antes do card de custo: "~X,X% ao ano (estimativa 30d, sem Impermanent Loss) ⓘ". Tooltip do ⓘ obrigatório com explicação de IL em linguagem de usuário. Esta linha é obrigatória em toda proposta de LP da Kotai — nunca omitida.

f) Card de custo agregado (após campos preenchidos)

Total a depositar:   R$ X.XXX,XX
Gas estimado:        ~R$    XX,XX
──────────────────────────────────
Você paga agora:     R$ X.XXX,XX

Sub-label: "O total depositado permanece seu na posição — o gas é o custo para registrar na rede."

g) Slippage automático Campo simplificado: chip "Auto (X%)" com valor visível. Tooltip: "Margem de variação de preço aceita durante a transação. Calculado para este pool." Aviso inline quando Auto > 1% em modo V2: "⚠ Slippage acima de 1% para pool Simples — verifique se há liquidez suficiente."

h) Nota pedagógica inline 1 linha abaixo dos campos, antes do APR: "Neste modo, o protocolo distribui automaticamente seus tokens conforme a fórmula do pool. Você não precisa definir intervalos de preço." Botão de dismiss "Entendido ×" por sessão (não permanentemente — respeita Pilar 3 / proibição de "Don't show this again" em contexto relevante).

i) CTA principal Label dinâmico. Disabled até ambos os valores preenchidos + saldo suficiente.

Cosméticos

Saldo disponível abaixo de cada campo de aporte
Timestamp "Preço atual: R$ X.XXX,XX · Atualizado há N min" abaixo dos campos

3. Regras de Negócio

Proporção fixa V2: Ao inserir Token A: Token B = valor de A × (reserva de B / reserva de A no pool). Campo B não editável diretamente. Sub-label "(Calculado automaticamente com base no preço atual)" sempre visível. Se proporção inverter durante sessão (preço mudou): re-calcular Token B automaticamente e exibir nota "O valor foi recalculado com o preço atual."

Proporção StableSwap: Proporcional à composição atual do pool (pool desequilibrado aceita proporção não 50/50 com menor IL). A proporção calculada é exibida: "Proporção atual do pool: X% [Token A] / Y% [Token B]."

Validação par↔modo para StableSwap: Se par classificado como "não correlacionado" (heurística): banner amarelo inline aparece. O CTA não avança automaticamente — usuário deve clicar explicitamente "Continuar com risco entendido" (laranja) ou "→ Usar modo Concentrada" (primário). Ação explícita é obrigatória para continuar com par incompatível. Esta regra resolve o ponto isolado mais crítico do consolidado PancakeSwap (formulário aceitava BNB+CAKE em StableSwap sem nenhuma validação).

Saldo insuficiente: CTA nomeia o token específico em falta: "Saldo insuficiente em [Token A] · Comprar [Token A] →" (laranja). Link direto para on-ramp/compra.

Nota pedagógica: Visível por default na primeira visita à tela (baseado em sessão, não em persistência permanente). Estado de collapsed guardado por sessão. Na segunda visita na mesma sessão: collapsed por default. "Don't show this again" permanente é proibido — a nota pode ser relevante numa nova sessão.

Slippage: Auto por default. Para V2 pools grandes, geralmente < 0,5%. Aviso automático quando Auto > 1% (threshold mais baixo que em T02 — pools V2 são geralmente mais estáveis; slippage alto em V2 é sinal mais grave).

Aprovações de token: Sub-label no CTA "(Aprovação necessária)" quando tokens precisam de aprovação. Passo proativo ao avançar (padrão do design system Kotai de criar-pool-04).

Re-cálculo ao mudar preço: Se o preço do par mudar > 1% entre o momento de entrada na tela e o momento de submit: toast de aviso "O preço mudou. Valores recalculados." Proporção se atualiza automaticamente.

4. Estados Não-Triviais

Vazio: Campos zerados. Preset chips outline. Nota pedagógica visível. Card de custo não visível ainda. APR estimado visível com dados do pool. CTA "Inserir valores" disabled.

Loading de dados do pool: Skeleton nos campos de aporte (proporção do pool sendo carregada) e no APR. Se > 3s: "Buscando dados do pool... pode levar alguns segundos." Fallback com proporção estimada + indicador "(Estimativa — dados do pool sendo carregados)."

Par incompatível com modo StableSwap: Banner amarelo expandido inline. CTA principal travado até ação explícita: "→ Usar modo Concentrada" (primário verde) ou "Continuar com risco entendido" (laranja). O banner não tem dismiss silencioso — permanece até o usuário fazer uma escolha. Esta é a proteção crítica do fluxo.

Pool inativa (Vol/TVL < 0,001): Mini-card expandido forçado com banner vermelho. APR estimado exibe "~0,00% ao ano (pool inativa)" com ⓘ explicativo. CTA "Adicionar mesmo assim" (laranja). Nota pedagógica colapsada automaticamente para dar espaço ao banner de pool inativa.

Saldo insuficiente: CTA laranja com label dinâmico e sub-label: "Você tem R$ XX,XX · Necessário: R$ YY,YY."

Proporção recalculada (preço mudou): Toast: "O preço mudou. Valores recalculados." Token B atualiza silenciosamente. Se mudança > 5%: banner âmbar mais visível: "O preço de [Token A] mudou significativamente — verifique os valores antes de continuar."

Aprovação pendente: Sub-label no CTA "(Aprovação necessária)". Ao avançar: passo proativo de aprovação (design system).

Sucesso / Avanço: Stepper marca T03 como ✓. Transição para tela de revisão e confirmação. Toast contextual na tela de confirmação: "Posição Simples configurada · [Token A]/[Token B] · Proporção: XX%/YY%."

5. Microcopy Crítico

Mini-card de identidade — modo Simples:

"Você está adicionando em: [USDC/ETH] · Simples e passiva · ● Ativo"

Mini-card de identidade — modo Correlacionado:

"Você está adicionando em: [USDC/USDT] · Par correlacionado · StableSwap · ● Ativo"

Sub-label campo Token B:

"(Calculado automaticamente com base no preço atual)"

Proporção StableSwap:

"Proporção atual do pool: 52% USDC / 48% USDT"

Nota pedagógica:

"Neste modo, o protocolo distribui automaticamente seus tokens conforme a fórmula do pool. Você não precisa definir intervalos de preço." "Entendido ×"

APR com caveat obrigatório:

"~X,X% ao ano (estimativa 30d, sem Impermanent Loss) ⓘ"

Tooltip APR (texto completo):

"Estimativa baseada nas taxas coletadas nos últimos 30 dias neste pool. Não inclui Impermanent Loss — a diferença de valor entre manter os tokens e fornecê-los como liquidez. O Impermanent Loss pode reduzir ou zerar o retorno, dependendo da variação de preço entre os tokens."

Card de custo:

"Total a depositar: R$ X.XXX,XX" "Gas estimado: ~R$ XX,XX" "Você paga agora: R$ X.XXX,XX" "O total depositado permanece seu na posição — o gas é o custo para registrar na rede."

Warning par incompatível (banner inline):

"⚠ [Token A] e [Token B] não se movem em conjunto — o modo Par correlacionado é otimizado para pares como USDC/USDT. Continuar pode resultar em perdas maiores por variação de preço entre os tokens." [→ Usar modo Concentrada] [Continuar com risco entendido]

Slippage chip:

"Auto (0,5%)"

Tooltip slippage:

"Margem de variação de preço aceita durante a transação. Calculado para este pool. Para ajustar: [Configurar →]"

Warning slippage V2 alto:

"⚠ Slippage acima de 1% para pool Simples — verifique se há liquidez suficiente neste pool."

Pool inativa:

"⚠ Pool com pouca atividade · Vol/TVL < 0,1% · Rendimento de taxas pode ser próximo de zero"

Proporção recalculada:

"O preço mudou. Valores recalculados."

CTA sequência:

"Inserir valores" → "Revisar aporte"

Saldo insuficiente:

"Saldo insuficiente em [Token A] · Comprar [Token A] →"

Pool inativa — CTA:

"Adicionar mesmo assim"

6. Rastreabilidade Obrigatória

🟢 Herdado

Stepper pedagógico: [uniswap-nova-posicao.md § Insight 1 — Stepper pedagógico e contextual]
Mini-card sticky de identidade: padrão estabelecido em visualizar-pool-04, visualizar-posicao-02 e adicionar-liquidez-02 no design system Kotai
CTA dinâmico com label de obstáculo específico: [pancake-final § Insight — Transparência proativa antes do CTA (parcial)]; padrão cross-fluxo do design system Kotai
Equivalente R$ em ambos os campos: [uniswap-final § Insight — Múltiplas representações do mesmo dado + bidirecionalidade]
APR com caveat obrigatório "~X% ao ano (estimativa 30d, sem IL) ⓘ": padrão obrigatório cross-fluxo estabelecido no design system Kotai (suas-posicoes, criar-pool, visualizar-posicao)
Linha-soma fechada "Total a depositar / Gas / Você paga agora": padrão de criar-pool-03 estabelecido no design system Kotai
Microcopy pedagógica inline que permanece visível (não em tooltip hover-only): [uniswap-nova-posicao.md § Insight 2 — Microcopy pedagógica inline]; quando uma consequência é eliminada pelo protocolo, manter a section visível e usar o espaço para educar
Preset chips de saldo com affordance honesta (outline em saldo = 0): padrão estabelecido em visualizar-pool-03 e adicionar-liquidez-02 no design system Kotai
Aprovação de token como passo proativo (não erro de recuperação): padrão de criar-pool-04 estabelecido no design system Kotai

🔴 Corrige

Validação inline par↔modo antes de avançar (warning explícito, CTA travado até ação): corrige [pancake-adicionar-liquidez.md § Ponto isolado, tela 4 — form aceita BNB+CAKE em StableSwap sem validação] + [pancake-adicionar-liquidez.md § Oportunidade 3 — Validação par↔protocolo inline]
Nota pedagógica sobre acoplamento de tokens (Campo B = calculado automaticamente): corrige [uniswap-nova-posicao.md § Fricção 1 — Versão como caixa-preta] (manifestação: usuário não entende por que o segundo campo muda automaticamente) + [uniswap-nova-posicao.md § Insight 2 — Microcopy pedagógica inline: quando decisão é eliminada por contexto, manter section visível e explicar]
APR com tooltip obrigatório de Impermanent Loss: corrige [uniswap-final § Fricção 6 — Métricas DeFi sem decomposição, janela ou comparativo] + [uniswap-pools.md § Oportunidade 1 — Sistema pedagógico de métricas DeFi: APR sem ancoragem de IL é promessa falsa]
Nota pedagógica colapsável por sessão — NÃO "Don't show this again" permanente: corrige [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência] (Pilar 3/7: "Don't show this again" proibido em contexto relevante para iniciante)
Slippage Auto com valor visível e threshold de alerta calibrado para V2 (> 1%): corrige [uniswap-nova-posicao.md § Ponto isolado — "Auto = 2,5%" sem critério]; threshold menor para V2 porque slippage alto em pool simples é sinal mais grave que em concentrada
Labels e microcopy inteiramente em PT-BR com tooltip de IL em português: corrige [pancake-adicionar-liquidez.md § Fricção Sistêmica — Localização incompleta: inglês técnico dentro de UI PT-BR] + [pancake-final § Fricção 2 — i18n parcial e inconsistente]

🟡 Captura

Validação par↔protocolo como diferenciador de proteção ao iniciante: [pancake-adicionar-liquidez.md § Oportunidade 3 — Validação par↔protocolo inline antes do aporte]. Hipótese: usuário que recebe warning de "BTC/ETH não é par correlacionado" e troca para modo Concentrada tem IL menor e NPS mais alto na primeira posição LP. Nenhum DEX analisado entrega esta proteção.
APR com tooltip narrativo de IL (educação no ponto de decisão): [uniswap-pools.md § Oportunidade 1 — Sistema pedagógico de métricas DeFi: re-label + tooltip de IL]. Hipótese: usuário que lê "~X% ao ano sem Impermanent Loss" tem expectativas calibradas, menor taxa de abandono/reclamação no primeiro mês.
Modo passivo como path simplificado para iniciante (sem range, formulário mínimo): derivado de [pancake-adicionar-liquidez.md § Oportunidade 1 — Entrada por intenção] + [uniswap-nova-posicao.md § Oportunidade 1 — Path B para iniciante]. A simplificação de T03 vs. T02 é a realização prática da filosofia "Simples e passiva" para o perfil iniciante do target.

⚪ Novo

Nota pedagógica inline colapsável por sessão (não permanentemente): sem precedente como componente nomeado nos consolidados. Justificativa: o iniciante que entra pela primeira vez no modo Simples não tem o modelo mental de "acoplamento de tokens pela fórmula constant product" — o Campo B que se calcula sozinho parece um bug sem a nota. O dismiss por sessão (não permanente) respeita o Pilar 3 (proibição de "Don't show this again" em contexto relevante) enquanto evita repetição irritante para o usuário que já entendeu. Evidência a coletar: taxa de interação com o dismiss "×" vs. taxa de tickets de suporte "por que não consigo digitar no segundo campo?".
Re-cálculo automático com toast quando preço muda > 1% durante sessão: sem precedente nos consolidados. Justificativa: o usuário pode deixar a tela aberta, voltar, e ter proporções desatualizadas. O toast evita submit silencioso com valores stale. Custo: polling de preço com TTL de 30s (já existe em visualizar-posicao-01 do design system). Evidência a coletar: frequência de "preço mudou" durante sessão vs. taxa de falha de transação por slippage.
Warning de slippage com threshold diferenciado por modo (V2 < 1%, Concentrada < 2%): sem precedente explícito nos consolidados. Justificativa: um slippage de 2% em V2 indica problema real (pool com pouca liquidez); em V3/V4 concentrado, é mais comum por razões arquiteturais. Mesma mensagem de aviso com thresholds diferentes entrega informação calibrada ao contexto. Custo: lógica de threshold condicional por modo — trivial de implementar. Evidência a coletar: correlação entre aviso de slippage e taxa de abandono do formulário.

7. Trade-offs e Segunda Ordem

Validação par↔protocolo: Exige heurística de classificação de par mantida por equipe de produto. Se a heurística classificar incorretamente um par como "não correlacionado" quando ele se movimenta em conjunto (ex: WBTC/BTC em alguns mercados), o warning é falso positivo — cria atrito desnecessário para o usuário avançado. Mitigação: threshold conservador; "Continuar com risco entendido" sempre disponível como escape; revisão da heurística trimestral com dados de IL realizado por modo.

Nota pedagógica colapsável: Adiciona string de UI por modo de provisão. Custo de i18n: ~3 strings por modo × 3 modos = 9 strings pedagógicas por idioma. Mitigação: componente reutilizável com prop de conteúdo (não hardcoded por tela).

Campo Token B não editável: Pode gerar fricção para o usuário que prefere inserir pelo Token B (ex: "quero depositar exatamente 100 USDT"). Mitigação: tooltip no ícone de cadeado com "Para definir um valor específico de USDT, edite o campo USDC acima." Alternativa futura: campo de input alternativo que travoca A e B como "âncora" do cálculo. Decisão adiada para segundo release — o comportamento atual é mais previsível e alinhado com como o protocolo funciona.

APR tooltip com link "Saiba mais": O link de educação sobre IL aponta para conteúdo externo ou interno. Se externo: dependência de URL que pode mudar; se interno: custo de produção e manutenção de conteúdo pedagógico. Mitigação de MVP: tooltip autocontido (sem link) com texto completo de 3 linhas.

Re-cálculo automático de proporção: Polling de preço a cada 30s gera chamadas contínuas enquanto a tela está aberta. Em mobile com conexão fraca: pode causar piscar dos campos ao atualizar. Mitigação: debounce de 5s antes de aplicar novo valor; atualização silenciosa sem re-renderização completa do formulário.

Separação T02/T03 vs. tela bifurcada: A mesma observação de T02 se aplica: dois screens de configuração aumentam a superfície de manutenção. O benefício é que T03 é fundamentalmente mais simples que T02 (sem range, sem fee tier dinâmico, sem gráfico de distribuição de liquidez) — a separação evita que o iniciante seja exposto à complexidade do modo Concentrado ao escolher o modo Simples.

Portfólio — Tela 04: Modal "Receber tokens" (fluxo guiado token-rede-first)

1. Função da tela

Permite ao usuário receber criptoativos na carteira Kotai com proteção ativa contra o principal vetor de perda não-maliciosa em DeFi — enviar token em rede errada e perder fundos de forma irreversível. Substitui o paradigma de endereço cru por um fluxo guiado de 2 passos: escolha do token + rede, depois endereço com contexto. Foco: iniciante (quem mais sofre o vetor).

2. Componentes / elementos

Estruturais (definem o paradigma)

Step indicator (2 passos visíveis simultaneamente, passo ativo em destaque) Comunica ao usuário que há duas decisões a tomar antes do endereço aparecer — estabelece expectativa e reduz abandono por surpresa de fluxo longo.

Passo 1 — Seleção de token

Label: "Qual token você quer receber?"
Campo de busca com placeholder "Buscar por nome ou símbolo"
Lista de tokens: ordenada por (1) tokens já na carteira do usuário, (2) tokens recentemente usados, (3) trending por locale/rede ativa. Cada item: ícone + nome em PT-BR com símbolo técnico como secondary ("USDC – Dólar Digital") + chips inline de redes disponíveis ("Disponível em: Ethereum, Base +3").
Badges de emissão visíveis no item de lista: "Canônico", "Bridged via [rede]" com tooltip de 1 linha.

Passo 2 — Seleção de rede (habilitado após token selecionado)

Label: "Em qual rede você vai enviar?"
Lista filtrada: apenas redes onde aquele token existe com suporte verificado. Cada item: logo da rede + nome completo (nunca abreviação técnica — "Ethereum" não "EVM"; "BNB Chain" não "BSC") + taxa estimada de gas + badge "Recomendada" para rede com menor custo/conveniência para o locale detectado.
Seção "Redes não suportadas nesta versão": lista mínima com redes populares onde o token existe mas Kotai ainda não suporta (ex: Tron para USDT). Copy neutra: "USDT na Tron — não suportada nesta versão".

Endereço (pós-seleção de token + rede)

Ícone do token + ícone da rede no topo do card de endereço (identidade dupla sempre visível).
Aviso de segurança em destaque (banner âmbar ou vermelho, nunca neutro): "Envie APENAS [Token] na rede [Rede]. Outras combinações resultam em perda permanente de fundos."
Endereço truncado com expansão: 0xd09B…618a com botão de expansão para exibir completo.
CTAs: Copiar endereço | Mostrar QR Code — pareados, sem hierarquia visual entre eles.

Separador "Receber de uma plataforma de negociação"

Cards de CEX: detectadas por locale (BR → Mercado Bitcoin + Binance BR no topo; Coinbase como item internacional abaixo).
Cada card: logo + nome + tempo estimado de transfer heurístico + badge ↗ (sinaliza que abre fora do produto).
Link "Não vejo minha corretora →" expande inline para instrução de recebimento manual + link para Passo 1.

Link modo avançado (discreto, no rodapé do modal)

"Ver todos os endereços › (avançado)" — acesso ao paradigma original de endereço cru para usuário avançado. Preserva compatibilidade sem ser o caminho padrão.

Cosmético (polish)

"Precisa de ajuda?" no header do modal (link, não botão de destaque) — posicionado em modal de ação irreversível por padrão.
Ícone de chain correto para Solana (logo "sol" — nunca ampulheta cinza, que sinaliza loading/espera).
Indicador visual de passo ativo no step indicator (numeração + círculo preenchido).

3. Regras de negócio

Step 2 só habilita após token selecionado no Step 1. CTA do Passo 2 permanece desabilitado com label "Selecione o token primeiro" enquanto nenhum token estiver selecionado.
Lista de redes no Step 2 é filtrada dinamicamente: apenas redes onde o token selecionado existe com suporte verificado pela Kotai. Token não mapeado → seção "outras redes" com aviso.
Token canônico vs bridged: quando token tem versões canônica e bridged em redes diferentes, a versão canônica recebe badge "Original" e a bridged recebe badge "Bridged via [origem]" com tooltip: "Este [USDC] foi criado por ponte, não é o USDC original da Circle. Pode não ser resgatável fora desta rede."
Badge "Recomendada" na rede: algoritmo por locale (BR → Base se token disponível → Ethereum como fallback, priorizando menor gas atual) com indicador de custo ao lado.
CEX section: detecção de locale via IP/browser; BR → Mercado Bitcoin + Binance BR + Bybit BR primeiro; global → Coinbase + alternativas; sempre com badge ↗.
Copy do aviso de segurança é dinâmica: template com variáveis [Token] e [Rede] substituídas pelos valores selecionados. Exibida no momento em que o endereço aparece, não antes.
Toast na cópia do endereço: reforça contexto de rede no momento de maior risco de esquecimento: "Endereço copiado — use APENAS na rede [Rede]".
Modo avançado: ao clicar no link, modal exibe endereços por família (EVM agregado em um único endereço + Solana separada) sem step de seleção de token/rede. Banner de aviso permanece: "Certifique-se de usar a rede correta antes de enviar."

4. Estados não-triviais

Vazio / Step 1 sem busca ativa Lista pré-populada com tokens do portfólio do usuário (ordem por valor decrescente). Se portfólio vazio: tokens trending por locale. Nenhum campo em branco.

Loading Step 2 (verificando redes disponíveis) Skeleton de 2–3 items com copy: "Verificando redes disponíveis para [Token]…" Resolução < 500ms esperada; se persistir, exibe lista completa conhecida com aviso de atualização pendente.

Token sem suporte em nenhuma rede Kotai Não bloqueia — informa. Copy: "A Kotai ainda não suporta receber [Token] diretamente. Use o modo avançado com atenção ou transfira via corretora." Link para modo avançado + link para seção CEX.

Rede não suportada selecionada por engano Não aparece na lista do Step 2 (filtrada); seção colapsada "Redes não suportadas" disponível para expandir com copy neutra por rede.

Solana como família separada Card separado do EVM no Step 1 de seleção de token quando usuário tem SPL tokens. No Step 2, endereço Solana (Ed25519) exibido com badge "Solana — endereço diferente do EVM" para evitar confusão de usuários multi-chain.

CEX loading (OAuth) Spinner no card de CEX selecionada; timeout em 10s → "Não conseguimos conectar ao [CEX] agora. [Tentar de novo] [Usar endereço manual]".

CEX falha de OAuth Toast âmbar: "Não conseguimos conectar ao [CEX]. Use o endereço manual →" com link direto para Step 1 do fluxo guiado.

Endereço copiado (sucesso) Toast: "Endereço copiado — use APENAS [Token] na rede [Rede]." Toast persiste 5s e é dismissível.

5. Microcopy crítico

Elemento	Copy
Título do modal	Receber tokens
Subtítulo	Escolha o token e a rede para gerar seu endereço de recebimento
Label Passo 1	Qual token você quer receber?
Placeholder busca	Buscar por nome ou símbolo
Label Passo 2	Em qual rede você vai enviar?
Badge "Recomendada"	Recomendada — menor taxa agora
Aviso de segurança	Envie APENAS [Token] na rede [Rede]. Outras combinações resultam em perda permanente de fundos.
CTA cópia	Copiar endereço
CTA QR	Mostrar QR Code
Toast de cópia	Endereço copiado — use APENAS na rede [Rede]
Separador CEX	Receber de uma plataforma de negociação
Badge externo	↗ Abre fora do Kotai
Link CEX ausente	Não vejo minha corretora →
Link modo avançado	Ver todos os endereços › (avançado)
Pedir ajuda	Precisa de ajuda?
Rede não suportada	[Rede] — não suportada nesta versão
Badge bridged	Bridged via [rede de origem] ⓘ
Tooltip bridged	Este [Token] foi criado por ponte, não é o original. Pode não ser resgatável fora desta rede.
CTA desabilitado Step 2	Selecione o token primeiro
Loading Step 2	Verificando redes disponíveis para [Token]…
Token sem suporte	A Kotai ainda não suporta receber [Token] diretamente.
Falha OAuth CEX	Não conseguimos conectar ao [CEX]. [Tentar de novo] [Usar endereço manual]

6. Rastreabilidade obrigatória

🟢 Herdado

Agregação EVM em um único endereço (Ethereum + 17 L2s compartilham mesma curva Secp256k1 — um endereço serve para todas): [uniswap portfolio-04 § Insight 1]. Replicação consciente — listar N cards com o mesmo endereço seria poluição.
Solana separada como card próprio (Ed25519 ≠ Secp256k1 — incompatibilidade arquitetural, não decisão de UX): [uniswap portfolio-04 § Regras de negócio].
"Precisa de ajuda?" no header de modal de ação irreversível: [uniswap portfolio-04 § Insight 2] + [uniswap portfolio consolidado § Insights — Suporte contextual dentro de modais sensíveis]. Affordance de ajuda no momento de maior risco — não no footer global.
Distinção visual "endereço local" vs "integração externa" (CEX): herança e melhoria da dicotomia "De uma carteira" vs "De uma conta" identificada como insight herdável: [uniswap portfolio-04 § Insight 3]. Kotai adiciona badge ↗ para tornar a distinção explícita.
QR Code + Copiar como ações pareadas: [uniswap portfolio-04 § Insight 4]. Cobre os dois caminhos reais: copy para colar em app desktop, QR para escanear no celular.
Subtítulo em linguagem do usuário, não da indústria ("plataforma de negociação" em vez de "CEX"): [uniswap portfolio-06 § Insight 2] + [uniswap portfolio consolidado § Microcopy na linguagem mental do usuário].
Não fingir integrações que não existem (single-option modal com opção real em vez de 8 disabled cards): [uniswap portfolio-06 § Insight 1]. CEX section exibe apenas integrações funcionais.

🔴 Corrige

Fricção "token-rede mismatch — vetor #1 de perda real em DeFi": [uniswap portfolio-04 § Fricção 2] + [pancake-final § Fricção 4 — endereço sem identificador de rede]. Fluxo guiado de 2 passos elimina o endereço cru como artefato principal. User não recebe endereço sem saber para qual token+rede ele serve.
Fricção "+17 redes sem listar quais redes (e quais NÃO estão)": [uniswap portfolio-04 § Fricção 1]. Step 2 mostra apenas redes onde o token existe + seção "não suportadas" com copy neutra por rede.
Fricção "Coinbase como única CEX exclui geograficamente sem fallback": [uniswap portfolio-06 § Fricção 2] + [uniswap portfolio consolidado § Fricção — Exclusão geográfica]. CEX detectadas por locale: Mercado Bitcoin + Binance BR como primários para usuário BR.
Fricção "modal de Transferência com 1 única opção sem valor": [uniswap portfolio-06 § Fricção 1]. CEX section tem múltiplas opções reais hierarquizadas por relevância de locale.
Fricção "card de CEX visualmente idêntico a card de endereço": [uniswap portfolio-06 § Fricção 3]. Badge ↗ em todos os cards que redirecionam para OAuth/URL externa — distingue affordance local de integração externa.
Fricção "fragmentação multi-chain sem canonicidade": [uniswap-final § Fricção 2]. Badge "Canônico" / "Bridged via [rede]" com tooltip de risco distingue emissões e protege o iniciante de tratar tokens bridged como equivalentes ao canônico.

🟡 Captura

"Receber como fluxo guiado token-rede-first em vez de endereço-first": [uniswap portfolio-04 § Oportunidade] + [uniswap portfolio consolidado § Oportunidade — Receber guiado]. Hipótese de diferenciação: fluxo guiado com aviso dinâmico de token+rede elimina o principal vetor de perda do iniciante. Zero envio de USDT-TRC20 para endereço EVM porque o modal nunca exibe o endereço sem o contexto de token+rede. Passa nas 4 perguntas-teste: (1) ✓ todos os concorrentes entregam endereço cru (2) ✓ afeta iniciante diretamente (3) ✓ falta de investimento (4) ✓ ganho perceptível: diferença entre perder $500 e não perder.
"On-ramp e CEX local-first detectados por geografia": [uniswap portfolio consolidado § Oportunidade — On-ramp local-first] + [pancake-final § Pilar 7 — Mobile + BR/LatAm]. Hipótese: mostrar Mercado Bitcoin + Binance BR para usuário BR converte o caminho "teatral" do Uniswap em fluxo funcional. Passa nas 4 perguntas-teste.
"Seletor de rede contextualizado com escopo declarado": [uniswap portfolio consolidado § Oportunidade — Seletor de rede contextualizado]. Hipótese: lista de redes filtrada por token + seção "não suportadas" com redes populares elimina o cenário de "usuário envia em Tron achando que está incluída nas '17 redes'".

⚪ Novo

Badge "Recomendada" por algoritmo de locale + gas atual: sem precedente direto nos relatórios. Justificativa: iniciante BR sem contexto suficiente para escolher entre Base e Ethereum para receber USDC — a recomendação elimina decisão paralisante. Custo: algoritmo de recomendação com dados de gas em tempo real. Evidência a coletar: taxa de seleção da rede recomendada vs outras redes.
Toast de reforço de contexto de rede no momento da cópia: sem precedente exato. Justificativa: o único momento em que o usuário ainda pode mudar a rede é antes de enviar — reforço na cópia reduz erro de "copiei o endereço mas esqueci para qual rede era". Custo: 1 template de string extra. Evidência: taxa de suporte por token-rede mismatch antes/depois do lançamento.

7. Trade-offs e segunda ordem

Custo de UX (+1 passo no fluxo de recebimento): 2 passos vs 1 clique no modelo atual. Trivial vs custo de perda irreversível de fundos. Aceitar sem hesitação. Modo avançado (endereço cru) preserva o caminho de 1 clique para usuário avançado.

Mapa "token → redes suportadas" exige manutenção contínua: cada novo token adicionado precisa de mapeamento de redes. Custo de infra real, amortizável com o mesmo mapa usado em swap (seletor de token), pools (discovery) e visualizar-token.

Badge "Bridged" exige governança editorial: qual versão é o "canônico" de USDC — Ethereum mainnet, Base, ou outra? Requer critério público clicável ("como determinamos 'canônico'") para evitar percepção de endosso. Risco de litigation se Kotai classifica token incorretamente.

CEX local-first por locale: VPN users veem layout incorreto → botão "Não estou no Brasil" como fallback. Cada integração de CEX tem custo recorrente de manutenção (APIs mudam, KYC muda). MVP: Mercado Bitcoin + Binance BR + Coinbase (3 integrações); escalar após adoção validada.

i18n: aviso de segurança dinâmico usa template com variáveis [Token] e [Rede] — precisa validação de concordância em PT-BR para todos os tokens/redes (ex: "Envie APENAS Ether na rede Ethereum" vs "Envie APENAS USDC na rede Base"). Adicionar gênero gramatical ao registro de tokens é custo extra mas necessário para evitar copy quebrada.

QR Code com metadata de rede: alguns wallets leem metadata EIP-681 embutida no QR (rede + token no payload). Implementar quando disponível — reduz erro de rede errada no flow de scan.

Portfólio — Tela 05: Estado de erro/parcial (dados indisponíveis com diagnóstico declarativo)

1. Função da tela

Apresenta o portfólio quando uma ou mais fontes de dados falhou parcialmente — sem esconder a falha (honestidade visual), sem declarar o produto "quebrado" (catálogo declarativo de causas com ação e tempo estimado), mantendo operacionais as funcionalidades que ainda funcionam. Endereça simultaneamente o estado de gráfico em erro, o estado de conexão parcial EVM+Solana, e o timeout de skeleton de saldo. Foco: iniciante (quem interpreta falha parcial como produto quebrado e abandona) e intermediário (que precisa saber qual rede está com problema).

2. Componentes / elementos

Estruturais (definem o paradigma)

Banner de falha parcial (chip âmbar ancorado na área de dados, não no header global)

Um banner por fonte de dados falhando, posicionado acima dos dados afetados — não como header global que obscurece todo o produto.
Conteúdo: "[Rede] com atraso · dados podem estar desatualizados · [Recarregar]"
Se 2+ fontes falharem: condensa em "Dados de [N] redes indisponíveis · [Ver detalhes]" com expansão inline.
Ícone de status âmbar ao lado do nome da rede falhante no seletor de rede global.

Big stat de patrimônio em estado parcial

Exibe a soma das redes que responderam + asterisco em superscript.
Sub-label abaixo do número principal: "* Sem dados de [Solana] por ora" em cor âmbar.
Se nenhuma rede respondeu: skeleton + timeout escalonado (ver estados não-triviais).

Gráfico em estado de falha declarativo

Widget cinza com linha simulada (preserva o slot de layout — não colapsa o componente).
Tooltip declarativo expandido (não genérico "dados ausentes"): ícone de aviso + causa específica + ação + tempo estimado.
- Ex para indexador lento: "Histórico de [Rede] com atraso — normalmente resolve em ~30s · [Recarregar] · [Ver status da Kotai]"
- Ex para wallet sem histórico: "Sem histórico ainda — seu gráfico aparece após a primeira transação"
- Ex para RPC do usuário lento: "Pode ser sua conexão — [Testar conexão] · [Recarregar]"
Pills de timeframe desabilitadas enquanto gráfico está em estado de erro. Cada pill: visível mas cinza + tooltip ao toque/hover: "Disponível após os dados carregarem". Restauram ao estado ativo após retry bem-sucedido.

Skeleton de saldo com timeout escalonado

Skeleton padrão até 5s.
Após 5s sem resolução: sub-label âmbar abaixo do skeleton: "Demorando mais que o esperado · [Recarregar]".
Resolve a contradição de "gráfico já declarou erro terminal, saldo ainda em skeleton infinito" — [uniswap portfolio-05 § Fricção 2].

Tabs (Tokens / NFTs / Atividade) — operacionais independentemente

Tabs mostram dados das redes que responderam.
Banner contextual inline na tab afetada: "[Rede] com atraso — mostrando dados parciais". Não bloqueia a tab; informa o escopo.
Tabs de redes não afetadas: sem banner, experiência normal.

Cards de funding (Adicionar fundos / Receber tokens)

Sempre operacionais, independentemente do estado de dados do portfólio.
A falha de indexador não impede o usuário de receber ou adicionar fundos.

Cosmético

Bolinha âmbar ao lado do nome da rede falhante no seletor de rede global.
Link "Status da Kotai ›" no tooltip do gráfico (linkável para página de status externa — não enterrar como tooltip de tooltip).
Eyebrow de timestamp ao lado do big stat quando dado está stale (> 5 min sem refresh): "Atualizado às [HH:MM] · pode estar desatualizado".

3. Regras de negócio

Banner aparece quando qualquer fonte de dado retorna erro HTTP ou timeout > 5s. Não aparece em loading inicial — aguarda o timeout antes de declarar problema.
Big stat: soma das redes que responderam + sub-label asteriscado. Se nenhuma respondeu e timeout < 5s: skeleton puro. Se timeout ≥ 5s sem resolução: sub-label "Demorando mais que o esperado · [Recarregar]".
Pills de timeframe: desabilitadas (visíveis + cinza + tooltip "disponível após dados carregarem") enquanto gráfico estiver em estado de erro ou loading. Reabilitam assim que gráfico carrega com sucesso após retry.
Retry automático silencioso: a cada 30s em background sem interação do usuário. Chip "Atualizado às [HH:MM]" atualiza quando dado é refrescado.
Recuperação parcial: banner reduz dinamicamente (ex: de "2 redes com falha" para "1 rede com falha") sem necessidade de reload da página.
Stale data threshold: preços e saldo: banner âmbar após 2 min sem refresh. Gráfico: banner após 5 min. Atividade: banner após 10 min. (Critérios distintos porque relevância temporal varia por tipo de dado.)
Estado "wallet sem histórico" (distinto do estado de erro): gráfico em cinza com tooltip "Sem histórico ainda — seu gráfico aparece após a primeira transação." Não é erro — é estado esperado para wallet nova. Sem botão Recarregar (não há o que recarregar).
Diagnóstico de causa: sistema distingue 3 causas possíveis no tooltip do gráfico:
1. Indexador da Kotai lento → "Histórico de [Rede] com atraso — ~30s · [Recarregar]"
2. Wallet sem histórico → "Sem histórico ainda · aparece após a primeira transação"
3. Causa indeterminada → "Não conseguimos carregar o histórico. Pode ser conexão ou atraso no servidor. · [Recarregar] · [Ver status]"
Falha total (todas as redes falharam): banner vermelho cobrindo a área de dados com "Não conseguimos carregar seu portfólio · [Recarregar] · [Ver status da Kotai]". Cards de funding permanecem operacionais abaixo.

4. Estados não-triviais

Falha parcial — EVM ok, Solana falhou Banner âmbar: "Solana com atraso · [Recarregar]". Big stat com asterisco: "R$ X.XXX,XX " + sub-label " Sem dados de Solana por ora". Tab Tokens mostra apenas tokens EVM com banner inline "Mostrando apenas tokens EVM — Solana indisponível". Tab Atividade: idem.

Falha total — todas as redes falharam Banner vermelho acima de toda área de dados: "Não conseguimos carregar seu portfólio · [Recarregar] · [Ver status da Kotai]". Big stat: skeleton → após 5s: "— · [Recarregar]". Gráfico: widget cinza com tooltip de causa + fallback de diagnóstico. Cards de funding: operacionais.

Loading inicial (< 5s) Skeleton padrão no big stat. Gráfico: área cinza sem tooltip (ainda não é erro — é loading). Pills de timeframe: desabilitadas silenciosamente (sem tooltip — usuário ainda não tentou clicar).

Skeleton timeout (≥ 5s) Sub-label âmbar abaixo do skeleton do big stat: "Demorando mais que o esperado · [Recarregar]". Gráfico: tooltip declarativo com causa genérica + ação.

Wallet nova / sem histórico Gráfico em cinza com tooltip: "Sem histórico ainda — seu gráfico aparece após a primeira transação." Pills de timeframe: desabilitadas com tooltip "Disponível após a primeira transação". Sem banner de erro (não é falha).

Dado stale (> threshold por tipo) Eyebrow âmbar no big stat: "Atualizado às [HH:MM] · pode estar desatualizado". Botão inline: "[Atualizar]". Sem banner — stale data é menos urgente que falha total.

Recuperação (retry bem-sucedido) Toast verde: "Portfólio atualizado". Banner desaparece. Pills de timeframe reabilitadas. Big stat atualizado sem asterisco. Acontece silenciosamente em background — sem interrupção de fluxo do usuário.

Recuperação parcial (1 de 2 redes recuperadas) Banner reduz de "2 redes com falha" para "1 rede com falha" dinamicamente. Big stat atualiza sem asterisco para rede recuperada, mantém asterisco para rede ainda falhando.

RPC do usuário lento (causa externa) Tooltip do gráfico com diagnóstico diferenciado: "Pode ser sua conexão. · [Testar conexão] · [Recarregar]". Nota contextual: "Se o problema persistir, verifique sua conexão de internet."

5. Microcopy crítico

Elemento	Copy
Banner falha parcial	[Rede] com atraso · [Recarregar]
Banner múltiplas redes	Dados de [N] redes indisponíveis · [Ver detalhes]
Banner falha total	Não conseguimos carregar seu portfólio · [Recarregar] · [Ver status]
Sub-label big stat parcial	* Sem dados de [Solana] por ora
Sub-label timeout skeleton	Demorando mais que o esperado · [Recarregar]
Sub-label falha total big stat	— (em vez de número) · [Recarregar]
Tooltip gráfico — indexador lento	Histórico de [Rede] com atraso — normalmente resolve em ~30s · [Recarregar] · [Ver status]
Tooltip gráfico — wallet nova	Sem histórico ainda — seu gráfico aparece após a primeira transação
Tooltip gráfico — causa genérica	Não conseguimos carregar o histórico. Pode ser conexão ou atraso. · [Recarregar] · [Ver status]
Tooltip pills desabilitadas	Disponível após os dados carregarem
Tooltip pills — wallet nova	Disponível após a primeira transação
Banner tab afetada	[Rede] com atraso — mostrando dados parciais
Toast recuperação	Portfólio atualizado
Eyebrow stale	Atualizado às [HH:MM] · pode estar desatualizado
CTA inline stale	Atualizar
Tooltip RPC do usuário	Pode ser sua conexão · [Testar conexão] · [Recarregar]
Link status externo	Ver status da Kotai ↗

6. Rastreabilidade obrigatória

🟢 Herdado

Tooltip declarativo preserva o slot do gráfico em vez de ocultar o widget: [uniswap portfolio-05 § Insight 1]. "Dados do gráfico ausentes" do Uniswap é padrão correto de honestidade visual — Kotai expande com causa + ação + tempo.
Skeleton separado por fonte de dado (saldo ≠ gráfico): [uniswap portfolio-05 § Insight 2]. Saldo e gráfico carregam de fontes distintas; dois estados de loading separados reduzem a frustração de "está tudo carregando há 10s".
Error/empty state declarativo supera silêncio: [uniswap-final § Insights — Estados como instrução acionável]. Suprimir o widget é pior que explicá-lo.
Cobertura proativa de estados não-triviais (conexão parcial EVM+Solana): [pancake-final § Insights — Cobertura proativa de estados não-triviais]. Pancake cobre conexão parcial EVM+Solana como estado de tela dedicada — padrão a herdar na forma de banner por família de rede.
CTAs de funding operacionais independentes do estado de dados: herança do padrão "ações de saída sempre disponíveis" — falha de indexador não bloqueia a capacidade de o usuário adicionar fundos.

🔴 Corrige

Fricção "copy de error state sem diagnóstico nem caminho de recuperação": [uniswap portfolio-05 § Fricção 1]. Tooltip declarativo com 3 variantes de causa (indexador / wallet nova / causa genérica) + ação + tempo estimado substitui "Dados de saldo do portfólio indisponíveis."
Fricção "skeleton de saldo + erro declarado no gráfico = signal contraditório": [uniswap portfolio-05 § Fricção 2]. Timeout escalonado de 5s para skeleton: skeleton → sub-label âmbar "Demorando mais que o esperado · [Recarregar]". Resolve a contradição de "gráfico declarou erro terminal mas saldo continua em skeleton infinito."
Fricção "timeframe pills permanecem ativas no estado de erro (affordance morta)": [uniswap portfolio-05 § Fricção 3] + [uniswap portfolio consolidado § Fricção estrutural — Affordances interativas ativas em estados onde não funcionam]. Pills desabilitadas com tooltip explicativo — preservam valor pedagógico (controles visíveis) sem custo de clique morto. Restauram ao estado ativo no retry bem-sucedido.
Fricção "léxico de protocolo como vocabulário primário": [pancake-final § Fricção 1]. "Histórico de Base com atraso" em vez de "Subgraph indisponível"; "Solana com atraso" em vez de "RPC endpoint SVM timeout".

🟡 Captura

"Error states com diagnóstico + ação em vez de copy genérica": [uniswap portfolio-05 § Oportunidade] + [uniswap portfolio consolidado § Oportunidade — Error states com diagnóstico]. Hipótese: "Histórico de Base com atraso — ~30s" converte "produto quebrado" em "problema localizado e temporário" → retenção do iniciante que abandonaria ao ver mensagem genérica. Passa nas 4 perguntas-teste: (1) ✓ todos os concorrentes usam copy genérica de erro (2) ✓ afeta iniciante diretamente (3) ✓ falta de investimento em catálogo de causas (4) ✓ ganho perceptível — o iniciante diferencia "feature com atraso" de "produto quebrado".
"Default contextual em camadas": [uniswap-final § Pilar 4] + [pancake-final § Pilar 6]. Banner por fonte de dado falhante (em vez de banner global único) é a expressão do default contextual no estado de erro — o contexto disponível (EVM respondeu, Solana não) é usado para informar o usuário com precisão.

⚪ Novo

Banner por fonte de dado falhante (em vez de banner global único): sem precedente direto nos relatórios. Justificativa: iniciante BR com portfólio EVM+Solana vê claramente "meu ETH está acessível, o problema é só no Solana" — reduz abandono porque a falha é localizada, não total. Custo: lógica de composição de banners por família de rede; evidência a coletar: taxa de abandono em estado de erro parcial vs estado de erro total.
Timeout escalonado de 5s (skeleton → sub-label âmbar): solução específica para a fricção diagnosticada, sem precedente exato. Justificativa: resolve a contradição de skeleton infinito + erro declarado. O valor de 5s é heurístico — coletar dados reais de P90 de load time para calibrar. Custo: timer de componente; zero impacto em casos de load normal (< 1s na maioria dos casos).
3 variantes de tooltip de gráfico por causa (indexador / wallet nova / genérico): design de catálogo declarativo sem precedente exato nos concorrentes. Justificativa: causa "wallet nova" e causa "indexador lento" exigem cópias radicalmente diferentes — copiar o mesmo tooltip para ambas desinforma. Custo: lógica de detecção de causa no backend (já necessária para distinguir "erro" de "sem dados históricos").

7. Trade-offs e segunda ordem

Catálogo de causas exige manutenção contínua: cada nova fonte de dado, cada nova rede, cada novo provider de indexador precisa do seu error state declarado. Custo real. Mitigável com template padronizado de 3 campos (causa, ação, tempo estimado) que qualquer engenheiro preenche ao adicionar nova feature. Regra: error state declarado é bloqueador de PR para features novas com fonte de dado externa.

Diagnóstico errado pode ser pior que copy genérica: se o sistema diagnosticar "indexador com atraso" mas o problema real for na carteira do usuário, a copy misleads. Solução: fallback sempre disponível ("ou pode ser sua conexão — [Testar conexão]") em todas as variantes de tooltip. Diagnóstico correto é melhoria sobre genérico; diagnóstico errado com fallback é neutro.

Banner por fonte de dado falhante pode crescer demais: se 3+ fontes falharem simultaneamente, banner area cresce e comprime o conteúdo útil. Banner condensa após N=2 falhas simultâneas em mensagem agregada "Dados de [N] redes indisponíveis · [Ver detalhes]" com expansão inline. N=2 é heurístico — ajustar por viewport (mobile condensa em N=1).

Retry automático em background (30s) tem custo de RPC: desabilitar para carteiras com muitas redes quando app está em background (Page Visibility API). Em foreground: retry ativo. Em background: suspend e retomar ao foreground.

Stale data threshold é arbitrário: preços em DeFi mudam a block time (~12s); dado de 5 min pode ser irrelevante. Definir thresholds distintos por tipo de dado (preço: 2 min; gráfico: 5 min; atividade: 10 min) e expor como configuração avançada no settings para intermediário que precisa de dados frescos.

Notação do big stat com asterisco: asterisco como indicador de "dado incompleto" é convenção de relatórios financeiros, não de apps mobile. Alternativa: eyebrow de cor âmbar + tooltip explicativo. Testar ambos via A/B; priorizar legibilidade em mobile (asterisco pode ser difícil de tocar).

Portfólio — Tela 06: Modal "Adicionar fundos" (on-ramp local-first BR/LatAm)

1. Função da tela

Permite ao usuário iniciante BR/LatAm adicionar fundos à carteira Kotai através de caminhos reconhecíveis e funcionais no contexto local — PIX/TED como on-ramp primário, Mercado Bitcoin/Binance BR como transferência de CEX — em vez do paradigma global-first (Moonpay + Coinbase) que é teatral para o target. Consolida os 3 cards de funding do Uniswap (Compre criptos / Receber criptos / Transferência) em um único modal organizado por intenção, com detecção de locale. Foco: iniciante (principal — primeiro funding é a barreira mais concreta entre ele e a primeira operação real).

2. Componentes / elementos

Estruturais (definem o paradigma)

Header do modal

Título: "Adicionar fundos"
Link "Precisa de ajuda?" à esquerda (pattern consistente com portfolio-04 — ajuda contextual em modal de ação financeira, não no footer global).
Botão X fechar à direita.

Seção 1 — Comprar com reais (ação de menor fricção para iniciante sem cripto)

Label da seção: "Comprar com reais" (não "Comprar criptos" — perspectiva do usuário, não do produto).
Card principal (BR locale): "PIX ou transferência bancária" + badge "Mais rápido e barato no Brasil" + taxa estimada: "Taxa estimada: ~1,5% · Instantâneo" + botão CTA primário.
Card secundário: "Cartão de crédito ou débito" + taxa estimada: "Taxa estimada: ~3–5%".
Nota de conversão abaixo dos cards: "Pague em reais e receba cripto direto na sua carteira."
Logo dos parceiros como "Powered by [logo]" — discreta, não dominante. Parceiro não é o produto.
Fee sempre visível antes do clique — não enterrada no flow do parceiro.

Seção 2 — Transferir de uma corretora (para usuário com conta em CEX)

Label da seção: "Transferir de uma corretora" (não "CEX" — linguagem mental do usuário).
Cards de CEX detectadas por locale:
- BR → Mercado Bitcoin + Binance BR (primários) + Coinbase (internacional, abaixo).
- Cada card: logo + nome completo + tempo estimado heurístico ("Transfer em ~5 min") + badge ↗ Abre fora do Kotai.
Link de escape inline: "Não vejo minha corretora →" — expande a lista de CEX suportadas + instrução "Use o endereço de recebimento" com link para modal portfolio-04.
Nenhuma CEX não-integrada listada como "em breve" ou disabled — não fingir features que não existem.

Seção 3 — De outra carteira (link, não seção expandida)

Label: "Receber de outra carteira ou rede →"
Clique abre diretamente o modal portfolio-04 (fluxo guiado de recebimento).
Não expandida inline — intenção menos comum para iniciante sem fundos; mantém modal focado.

Rodapé

"Fora do Brasil? Ver opções internacionais ›" — link para versão sem locale-first.
Detectado como non-BR: layout inverte ordem (Cartão como card principal, PIX vira opção regional).

Cosmético

Ícone de seta ↗ padronizado para todos os cards que redirecionam para OAuth/URL externa.
Logo dos parceiros em tamanho reduzido, sem cor dominante — parceiro é infraestrutura, não co-branding.
Separadores visuais claros entre as 3 seções (linha leve + label de seção).

3. Regras de negócio

Detecção de locale: via IP + browser locale. BR → PIX como card principal em Seção 1. Non-BR detectado → Cartão como card principal. VPN ou detecção ambígua → botão "Não estou no Brasil" sempre visível, abre versão global.
Fee estimada sempre visível antes do clique: taxa estimada renderizada inline no card, não no flow do parceiro. Usar "Taxa estimada: ~X%" para indicar que é estimativa sujeita a confirmação.
Seção 1 em destaque quando saldo = 0: "Comprar com reais" como seção de topo. Quando saldo > 0: header do modal muda para "Adicionar mais fundos", mas ordem das seções permanece igual.
CEX local-first por locale:
- BR: Mercado Bitcoin + Binance BR + Bybit (se disponível) + Coinbase como item internacional.
- MX: Bitso + Binance MX + Coinbase.
- Global: Coinbase + Binance + outros disponíveis.
Tempo de transfer heurístico por CEX: estimativas baseadas em histórico de confirmações típicas (MB ~5 min, Binance BR ~2 min, Coinbase ~5 min). Label: "Transfer em ~[X] min" — não promessa, estimativa.
Badge ↗ em todos os cards externos: qualquer card que redireciona para OAuth/URL externa recebe badge ↗ Abre fora do Kotai. Diferencia affordance local (endereço copiado, ação local) de integração externa (sai do produto).
Handoff tracking: após redirecionar para parceiro de on-ramp ou CEX, banner persistente aparece no app: "Operação em andamento via [Parceiro] · Iniciada às [HH:MM] · [Ver status]". Polling passivo a cada 30s; stop após 30 min sem confirmação → "Se você pagou mas o saldo não atualizou, [Pedir ajuda]".
Provider indisponível: card sombreado + badge "Temporariamente indisponível" + fallback automático para próximo provider disponível. Não remove o card — preserva posição e explica o estado.
"Não vejo minha corretora" link: expande inline uma lista estendida de CEX suportadas. Se CEX do usuário não está em nenhuma → instrução "Use o endereço de recebimento manual" com link para portfolio-04 + nota de como sacar de CEX genérica.
Locale não detectado / VPN: layout global como fallback + botão "Estou no Brasil" para forçar locale BR.
Handoff em andamento (usuário reabre o modal): banner âmbar no topo do modal: "Operação via [Parceiro] em andamento · [Ver status]". Não bloqueia nova operação.

4. Estados não-triviais

Usuário sem saldo (estado inicial típico) Seção 1 (Comprar) em destaque. Header: "Adicionar fundos". PIX como card principal (locale BR). Cards de CEX visíveis abaixo.

Usuário com saldo existente (adicionando mais) Header: "Adicionar mais fundos". Ordem das seções idêntica — não inflar as opções só porque saldo existe.

Loading de providers disponíveis Skeleton de 2 cards em Seção 1 e 2 simultaneamente. Copy acima: "Carregando opções disponíveis para você…" Timeout em 5s: fallback para lista estática de providers conhecidos com nota "Taxa pode variar — confirme no parceiro".

Provider de on-ramp indisponível Card sombreado + badge cinza "Temporariamente indisponível". Fallback automático para próximo provider. Se todos os providers de PIX indisponíveis: seção 1 exibe Cartão como único card disponível + nota "PIX temporariamente indisponível — tente em alguns minutos".

Locale não detectado ou VPN Layout global: Cartão como card principal, sem badge "Mais popular no Brasil". Botão "Estou no Brasil →" visível como ação secundária no rodapé.

Handoff em andamento — usuário volta ao app Banner âmbar no topo do modal: "Operação via [Parceiro] em andamento · Iniciada às [HH:MM] · [Ver status]". Nova operação não bloqueada — usuário pode iniciar outra se quiser.

Handoff concluído (webhook ou polling bem-sucedido) Toast verde: "Fundos adicionados! Seu saldo foi atualizado." Banner de handoff dismissível automaticamente. Saldo no portfólio atualizado sem reload.

Handoff timeout (30 min sem confirmação) Banner âmbar muda para: "Sua operação pode estar pendente. Se você pagou e o saldo não atualizou, [Pedir ajuda]." Não declara erro — pagamento pode estar em processamento.

Erro de OAuth de CEX Toast âmbar: "Não conseguimos conectar ao [CEX]. [Tentar de novo] [Usar endereço manual]". Link "Usar endereço manual" abre portfolio-04.

CEX do usuário não listada "Não vejo minha corretora →" expande: lista completa de suportadas + instrução "Minha corretora não está na lista" → instrução genérica de saque + link para portfolio-04 com nota contextual.

5. Microcopy crítico

Elemento	Copy
Título do modal	Adicionar fundos
Título quando saldo > 0	Adicionar mais fundos
Subtítulo	Escolha como quer financiar sua carteira
Label Seção 1	Comprar com reais
Card PIX	PIX ou transferência bancária
Sub-label PIX	Taxa estimada: ~1,5% · Instantâneo
Badge PIX	Mais rápido e barato no Brasil
Card Cartão	Cartão de crédito ou débito
Sub-label Cartão	Taxa estimada: ~3–5%
Nota de conversão	Pague em reais e receba cripto direto na sua carteira
Label Seção 2	Transferir de uma corretora
Sub-label por CEX	Transfer em ~[X] min · taxa de saque da corretora
Badge externo	↗ Abre fora do Kotai
Link CEX ausente	Não vejo minha corretora →
Label Seção 3	Receber de outra carteira ou rede →
Rodapé locale	Fora do Brasil? Ver opções internacionais ›
Botão locale inverso	Estou no Brasil →
Banner handoff ativo	Operação via [Parceiro] em andamento · Iniciada às [HH:MM] · [Ver status]
Banner handoff timeout	Sua operação pode estar pendente. Se você pagou, [Pedir ajuda].
Toast sucesso	Fundos adicionados! Seu saldo foi atualizado.
Erro OAuth	Não conseguimos conectar ao [CEX]. [Tentar de novo] [Usar endereço manual]
Provider indisponível	Temporariamente indisponível
Loading providers	Carregando opções disponíveis para você…
CEX não listada — instrução	Não encontrou sua corretora? Use o endereço de recebimento manual →
Pedir ajuda	Precisa de ajuda?

6. Rastreabilidade obrigatória

🟢 Herdado

"Precisa de ajuda?" no header de modal de ação financeira (pattern consistente cross-modais de funding): [uniswap portfolio-04 § Insight 2] + [uniswap portfolio-06 § Insight 3] + [uniswap portfolio consolidado § Insights — Suporte contextual dentro de modais sensíveis]. Affordance de ajuda no momento de maior risco — não no footer global.
Distinção por intenção: "Comprar" vs "Transferir" vs "De outra carteira" como três jornadas separadas: herança e reorganização dos 3 cards de funding do Uniswap portfolio-01. Cada caminho serve uma intenção distinta — manter separados evita confusão de qual usar.
Subtítulo em linguagem do conceito do usuário ("corretora" em vez de "CEX"; "plataforma de negociação" mantida como precedente do Uniswap): [uniswap portfolio consolidado § Microcopy na linguagem mental do usuário] + [uniswap portfolio-06 § Insight 2]. Iniciante BR lê "corretora" e reconhece; "CEX" é jargão da indústria.
Não fingir integrações que não existem (single-option real em vez de N disabled "em breve"): [uniswap portfolio-06 § Insight 1]. CEX section exibe apenas integrações funcionais; provider indisponível recebe badge de estado, não é removido da lista.
Fee exibida antes do clique (não enterrada no flow do parceiro): [pancake-final § Pilar 4 — Transparência proativa antes do CTA] + [pancake-final § Insights — Transparência proativa antes do CTA]. Breakdown "provedor / plataforma / câmbio" como precedente; Kotai implementa taxa estimada visível inline no card.
Seção "Comprar" em destaque quando saldo = 0: herança do padrão "default contextual" — [uniswap-final § Insights — Defaults agregados que respeitam modelo mental] + [pancake-final § Pilar 6 — CTA dinâmico + Default contextual]. Contexto disponível (saldo = 0) informa a hierarquia de seções.
Empty state com instrução acionável vs decoração passiva: [uniswap portfolio consolidado § Insights — Empty state convertido em instrução acionável]. Se usuário chega sem saldo, modal não é decorativo — cada seção entrega instrução concreta com CTA.

🔴 Corrige

Fricção "Exclusão geográfica nos dois pontos de entrada de funding": [uniswap portfolio consolidado § Fricção estrutural — Exclusão geográfica nos pontos de entrada de funding]. On-ramp local-first (PIX/TED como card principal) + CEX BR detectadas por locale substitui on-ramp global + Coinbase-only que são teatrais para usuário BR.
Fricção "Coinbase como única CEX exclui geograficamente sem caminho fallback": [uniswap portfolio-06 § Fricção 2]. CEX section com Mercado Bitcoin + Binance BR para locale BR. Link de escape para usuário cuja CEX não está listada.
Fricção "modal de Transferência com 1 única opção é overhead sem valor": [uniswap portfolio-06 § Fricção 1]. Modal com 3 seções distintas, cada uma com pelo menos 2 opções reais, justifica o nível de modal.
Fricção "card de CEX visualmente idêntico a endereço local": [uniswap portfolio-06 § Fricção 3]. Badge ↗ Abre fora do Kotai em todos os cards que redirecionam para OAuth/URL externa — distingue affordance local de integração externa.
Fricção "handoff ao provider externo sem rastro no app principal": [uniswap-final § Fricção 9 — handoff sem rastro] + [pancake-final § Fricção 8 — abandono em handoff]. Banner persistente "Operação em andamento via [Parceiro] · [Ver status]" visível no app mesmo após o usuário fechar o modal. Polling passivo a cada 30s.
Fricção "defaults ignoram contexto que o sistema já tem": [uniswap-final § Fricção 4]. Locale detectado por IP/browser informa a hierarquia de providers — não apresentar lista global genérica para usuário BR quando o sistema já tem o sinal de locale.

🟡 Captura

"On-ramp e CEX local-first detectados por geografia": [uniswap portfolio consolidado § Oportunidade — On-ramp e CEX local-first] + [pancake-final § Pilar 7 — Mobile-first + Localização BR/LatAm como infraestrutura] + [uniswap-final § Pilar 1 — Localização BR/LatAm como infraestrutura]. Hipótese de diferenciação: PIX como método default para BR + CEX BR como opção principal converte o caminho "teatral" do Uniswap (onde o usuário BR não reconhece nenhum caminho funcional e abandona) em fluxo que o usuário BR reconhece na primeira tela. 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 (4) ✓ ganho perceptível: PIX em segundos vs cartão internacional com 3–7% de taxa.
"Transparência de fee antes do clique": [pancake-final § Pilar 4 — Educação contextual + Transparência financeira]. Taxa estimada visível inline no card antes do clique elimina a surpresa de taxa no flow do parceiro. Hipótese: usuário que vê "~1,5%" antes de clicar tem expectativa calibrada e conclui o flow com menor taxa de abandono pós-clique.
"Handoff com estado persistente no app principal": [uniswap-final § Pilar 1 — Localização BR/LatAm] (item "faixa persistente de compra em andamento"). Banner de handoff com polling transforma a experiência de "paguei no PIX, sumiu no ar" em "compra em andamento via [Parceiro] · iniciada às [HH:MM]" — reduz suporte e abandono no período de espera.

⚪ Novo

Handoff tracking com banner persistente + polling passivo: baseado em fricções diagnosticadas nos dois relatórios finais, mas a solução específica (banner no modal + polling 30s sem webhook obrigatório) é nova. Justificativa: usuário BR que paga via PIX e volta ao app fica sem confirmação durante 2–5 min — vetor de abandono e tickets de suporte. Banner transforma espera opaca em espera informada. Custo: polling passivo (custo de RPC baixo em 30s interval) + lógica de dismiss automático ao receber confirmação. Evidência a coletar: taxa de reabertura do modal / tickets de suporte "paguei mas não recebi" antes e depois.
"Não vejo minha corretora" como link de escape com expansão inline: sem precedente exato nos relatórios (Uniswap lista só Coinbase sem escape; Pancake lista parceiros sem escape). Justificativa: listar 20 CEX como disabled cards trai o Insight 1 de não fingir integrações; remover a seção de CEX trai o usuário que tem CEX suportada. Link de escape resolve sem enganar. Evidência: quais CEX os usuários buscam ao clicar no link (log de cliques + busca no campo de expansão).

7. Trade-offs e segunda ordem

Detecção de locale via IP: VPN users veem layout incorreto → fallback "Fora do Brasil? Ver opções internacionais ›" mitiga. Custo: 1 botão de override sempre visível. Edge case: usuário BR em VPN estrangeira perde PIX como default; edge case inverso (estrangeiro em IP BR) vê PIX como default sem utilidade.

Fee estimada como promessa implícita: "~1,5%" pode criar expectativa que o parceiro não entrega (taxa real pode variar por volume, método, regulação). Usar sempre "Taxa estimada: a partir de ~X%" + tooltip "Confirmada pelo parceiro no momento da operação". Documentar claramente que é estimativa.

Cada integração de CEX tem custo recorrente: APIs mudam, KYC muda, compliance muda por jurisdição. MVP: Mercado Bitcoin + Binance BR + Coinbase (3 integrações); escalar conforme adoção validada. Não adicionar CEX que ainda não está integrada — viola o princípio de não fingir features.

Polling de handoff: 30s interval em foreground, suspend em background (Page Visibility API). Stop após 30 min sem confirmação com mensagem de fallback para suporte. Risco de false negative: confirmação pode chegar após 30 min (delay de rede, delay de PIX em horário de pico). Opção: manter banner âmbar indefinidamente após 30 min (em vez de remover) com copy de fallback — usuário que recebeu ignora; usuário que não recebeu usa o link de suporte.

Ordem das seções (Comprar / Transferir / Outra carteira): Seção 3 como link em vez de seção expandida reduz comprimento do modal mas adiciona 1 clique extra para o caminho de recebimento manual. Para iniciante sem saldo, a intenção mais provável é comprar — Seção 3 como link é correto. Para usuário retornante com saldo em outra wallet, Seção 3 deveria ser mais acessível. Avaliar: se métricas pós-lançamento mostrarem alta taxa de clique em Seção 3, considerar promovê-la para seção expandida.

i18n: fee labels, nomes de CEX, tempos de transfer e copy de handoff precisam de revisão por locale (PT-BR, ES-MX, ES-AR, etc.). O template de banner de handoff com variáveis [Parceiro] e [HH:MM] precisa validação de formatação de hora por locale (PT-BR: 14:32; ES: 14:32; EN-US: 2:32 PM).

Cross-modal com portfolio-04: Seção 3 (link "Receber de outra carteira") e link de escape de CEX ausente ambos abrem portfolio-04. Garantir que fechar portfolio-04 retorna para este modal (não para a tela de portfólio) — contexto de navegação preservado.

Adicionar Liquidez — Tela 04: Revisão e Confirmação do Aporte

1. Função da tela

Tela de revisão final antes do commit on-chain — o usuário vê um sumário completo e imutável da posição que será criada (par, modo, valores, faixa de preço se Concentrada, custo total, APR estimado e risco de Impermanent Loss) e confirma conscientemente antes de qualquer token se mover. Foco: ambos iniciante e intermediário — o iniciante recebe pedagogia de risco no ponto de maior tensão; o intermediário encontra todos os dados para auditar sem precisar abrir outra tela.

2. Componentes / Elementos

Estruturais (definem o paradigma da tela)

a) Stepper horizontal "Par e modo" (✓ completo) | "Configurar" (✓ completo) | "Confirmar" (ativo — passo atual). Botão "← Editar" ao lado do stepper retorna para T02 ou T03 conforme o modo da posição, preservando todos os valores já preenchidos. Nunca destrói o formulário anterior.

b) Mini-card de identidade do pool (sticky no topo) Par + modo em label de benefício + fee tier + rede + badge de atividade compacto. Exatos mesmos dados e estilo que T02/T03 — design system estabelecido. Nunca removido durante a revisão. Em pool inativo: badge vermelho compacto ("Pool inativa") sem possibilidade de colapso.

c) Bloco de parâmetros da posição (estrutural — leitura do que foi configurado) Read-only. Nenhum campo editável. Cada linha tem label em PT-BR + valor + equivalente R$ quando aplicável.

Para modo Concentrada (V3/V4):

Faixa de preço: Mínimo R$ XX,XX — Máximo R$ XX,XX
Preset usado: "Equilibrado · ~70% do tempo in-range" (label exato como escolhido em T02)
Token A a depositar: X,XXXX [simbolo] (≈ R$ XXX,XX)
Token B a depositar: X,XXXX [simbolo] (≈ R$ XXX,XX)
Fee tier do pool: X,XX%

Para modo Simples (V2) e Par correlacionado (StableSwap):

Proporção do pool: XX% [Token A] / XX% [Token B]
Token A a depositar: X,XXXX [simbolo] (≈ R$ XXX,XX)
Token B a depositar: X,XXXX [simbolo] (≈ R$ XXX,XX)

d) APR estimado com caveat obrigatório "~X,X% ao ano (estimativa 30d, sem Impermanent Loss) ⓘ" — idêntico ao padrão obrigatório de T02/T03 e do design system Kotai. Tooltip do ⓘ idêntico ao de T03: decomposição do APR em linguagem de usuário com aviso de IL. Esta linha nunca é omitida.

e) Aviso de Impermanent Loss contextual (condicional — aparece para par não-correlacionado) Banner amarelo (não modal) com ícone ⚠: uma linha de texto + accordion "Entender o risco ▾" que expande sem sair da tela. Aparece apenas quando o modo não é "Par correlacionado" (StableSwap). Para o par correlacionado, o aviso é substituído por nota positiva: "StableSwap minimiza Impermanent Loss para este par."

Conteúdo do accordion expandido: explicação de IL em 3 frases, em linguagem de usuário, sem jargão de AMM. Nunca tem "Não mostrar novamente" — aviso Tier 2 no fluxo de LP.

f) Card de custo total (linha-soma fechada — mesmo padrão de T02/T03)

Total a depositar:   R$ X.XXX,XX
Gas estimado:        ~R$    XX,XX   [atualizar ↻]
──────────────────────────────────
Você paga agora:     R$ X.XXX,XX

Sub-label: "O total depositado permanece seu na posição — o gas é cobrado separadamente pela rede." Se aprovações necessárias: nota adicional abaixo — "Gas da aprovação: ~R$ XX,XX por token (cobrado antes desta etapa)."

g) Linha de slippage "Tolerância de slippage: Auto (X,X%) · [Ajustar →]". Link "Ajustar →" retorna para T02/T03 preservando todos os valores, com scroll automático para o componente de slippage. Read-only na T04 — para mudar, o usuário edita na tela anterior.

h) CTA principal Label dinâmico conforme o estado de aprovação:

Aprovações pendentes: "Autorizar tokens e adicionar liquidez" (primário azul/brand)
Sem aprovações pendentes: "Confirmar aporte" (primário azul/brand)

Disabled até: mini-card carregado + dados de gas disponíveis. Nunca verde — confirmar aporte não é ação destrutiva, mas é comprometimento financeiro irreversível. Cor primária brand (azul), não verde de validação.

Cosméticos

Ícone combinado do par (sobreposição dos dois avatares de token) no mini-card
Timestamp "Gas estimado atualizado há N min · [Atualizar ↻]" — botão de refresh manual
Separador visual entre bloco de parâmetros e bloco de custo
Label "Modo: [Simples e passiva / Concentrada em um intervalo / Par correlacionado]" como eyebrow secundário no bloco de parâmetros

3. Regras de Negócio

Read-only estrito: Nenhum campo na T04 é editável. Toda edição obriga retorno para T02/T03 via "← Editar". Dados passados por parâmetro do formulário anterior — nunca re-carregados da rede (evita discrepância silenciosa entre o que o usuário configurou e o que a tela exibe). Exceção: gas estimado, que é atualizado on-demand via botão "Atualizar ↻".

Gas estimado: Carregado ao entrar na T04 com TTL de 60s. Após TTL, badge âmbar: "Gas pode ter mudado · Atualizar ↻". CTA mantido habilitado — o usuário pode confirmar com estimativa desatualizada; o gas real na confirmação pode ser diferente. Ao submeter, o gas real é o cobrado pela rede, não necessariamente o estimado.

APR com dados insuficientes: Para pools com < 30 dias de histórico: "APR estimado: dados insuficientes para este pool. O rendimento dependerá do volume futuro."

Pool inativa detectada: Mini-card exibe badge "Pool inativa" em vermelho compact. O aviso de pool inativa de T02/T03 persiste aqui como lembrete — o usuário não pode ter "esquecido" entre as telas, mas a fricção é mantida consistente com o padrão estabelecido. CTA muda label: "Adicionar mesmo assim" (laranja). Sem delay aqui — o delay de 1,5s foi em T02; no T04, o usuário já demonstrou intenção consciente ao chegar até a revisão.

Aprovações necessárias: Se um ou ambos os tokens precisam de aprovação para o contrato LP da Kotai: nota no card de custo + label do CTA reflete. Ao clicar no CTA com aprovações pendentes, avança para T05 (aprovação proativa), não executa o aporte diretamente.

Sem aprovações necessárias: Ao clicar no CTA "Confirmar aporte", avança diretamente para T06 (resultado), pulando T05. O fluxo T05 é opcional e condicional — não aparece quando não é necessário.

Gas insuficiente: CTA: "Saldo de gas insuficiente · Comprar [moeda da rede] →" (laranja). Link abre on-ramp contextualizado para a moeda nativa da rede ativa.

4. Estados Não-Triviais

Loading (chegando de T02/T03): Skeleton no card de custo (gas sendo carregado) e no APR estimado (se não veio em cache). Mini-card com dados já disponíveis — não bloqueia render. CTA disabled durante loading. Se > 3s: "Carregando estimativas de custo..."

Gas desatualizado (> 60s): Badge âmbar "Gas pode ter mudado" no card de custo. Botão "Atualizar ↻" para refresh manual. CTA habilitado para o usuário que aceita o risco de gas diferente.

Pool inativa: Mini-card expandido com badge vermelho "Pool inativa". CTA laranja "Adicionar mesmo assim". Aviso de IL contextual para par volátil + aviso de pool inativa formam dois banners separados — não colapsam em um. Prioridade visual: pool inativa > IL risk.

Par incompatível confirmado pelo usuário em T01/T03: Banner âmbar discreto no topo do bloco de parâmetros: "⚠ Você escolheu continuar com par não-correlacionado em modo [StableSwap / Correlacionado] — o risco de IL é maior neste modo." Não é novo aviso — é lembrete do que o usuário já confirmou. Sem CTA de escape aqui — o usuário precisa usar "← Editar" se mudar de ideia.

Gas insuficiente: CTA laranja com label "Saldo de gas insuficiente · Comprar [ETH / BNB] →". Sub-label: "Gas necessário estimado: ~R$ XX,XX · Você tem: R$ YY,YY."

Dados do pool offline (RPC lento): Mini-card exibe "Dados do pool indisponíveis" com badge âmbar. APR estimado: "— (dados offline)". Card de custo: gas estimado mantido do cache (com badge de idade do dado). CTA habilitado com aviso inline: "Confirmar com dados possivelmente desatualizados."

Sucesso / avanço: Se aprovações necessárias → avança para T05. Se sem aprovações → avança para T06 com os parâmetros da posição como payload (par, modo, valores, tx hash pendente).

5. Microcopy Crítico

Título da tela:

"Revisar aporte"

Breadcrumb:

"Ganhar rendimento / Adicionar liquidez / Revisar"

Botão de edição:

"← Editar configuração"

Label do bloco de parâmetros:

"Resumo da posição"

Eyebrow de modo:

"Modo: Simples e passiva" / "Modo: Concentrada em um intervalo" / "Modo: Par correlacionado"

Faixa de preço (concentrada):

"Faixa de preço: R$ XX,XX – R$ YY,YY" "Preset: Equilibrado · ~70% do tempo in-range"

APR com caveat:

"~X,X% ao ano (estimativa 30d, sem Impermanent Loss) ⓘ"

Tooltip APR:

"Baseado nas taxas coletadas nos últimos 30 dias. Não inclui Impermanent Loss — a diferença de valor entre manter os tokens e fornecê-los. O Impermanent Loss pode reduzir ou zerar este retorno dependendo da variação de preço."

Aviso de Impermanent Loss (banner amarelo, par volátil):

"⚠ Ao fornecer liquidez em [Token A]/[Token B], o valor dos seus tokens pode cair se os preços divergirem — isso é chamado de Impermanent Loss." [Entender o risco ▾]

Accordion IL expandido:

"Impermanent Loss acontece quando o preço de um token muda em relação ao outro depois que você depositou. Quanto maior a divergência, maior a perda potencial. As taxas do pool podem compensar — mas não há garantia. É um risco estrutural de qualquer posição de liquidez em par de ativos voláteis."

Nota positiva StableSwap (substitui aviso de IL):

"✓ O modo Par correlacionado minimiza Impermanent Loss para pares como [Token A]/[Token B] — ativos que se movem em conjunto."

Card de custo — labels:

"Total a depositar" "Gas estimado · [Atualizar ↻]" "Você paga agora" "O total depositado permanece seu na posição — o gas é cobrado separadamente pela rede."

Nota de gas por aprovação:

"Gas da autorização: ~R$ XX,XX por token (cobrado antes desta etapa)"

Linha de slippage:

"Tolerância de slippage: Auto (X,X%) · [Ajustar →]"

CTA — sem aprovações:

"Confirmar aporte"

CTA — com aprovações:

"Autorizar tokens e adicionar liquidez"

CTA — pool inativa:

"Adicionar mesmo assim"

CTA — gas insuficiente:

"Saldo de gas insuficiente · Comprar [ETH / BNB] →"

Gas desatualizado:

"Gas pode ter mudado · Atualizar ↻"

Sub-label gas insuficiente:

"Gas necessário: ~R$ XX,XX · Você tem: R$ YY,YY"

Lembrete par incompatível confirmado:

"⚠ Você escolheu continuar com [Token A]/[Token B] em modo Correlacionado — o risco de Impermanent Loss é maior do que em par estável."

6. Rastreabilidade Obrigatória

🟢 Herdado

Stepper com labels dinâmicos e preservação de contexto ao retroceder: [uniswap-nova-posicao.md § Insight 1 — Stepper pedagógico e contextual]
Mini-card de identidade sticky (nunca removido durante ação contextualizada): padrão estabelecido em adicionar-liquidez-02, adicionar-liquidez-03, visualizar-pool-04 no design system Kotai
Linha-soma fechada "Total a depositar / Gas estimado / Você paga agora": padrão estabelecido em criar-pool-03 e adicionar-liquidez-02 no design system Kotai
APR com caveat obrigatório "~X% ao ano (estimativa 30d, sem IL) ⓘ": padrão obrigatório cross-fluxo do design system Kotai (suas-posicoes, criar-pool, adicionar-liquidez-02, adicionar-liquidez-03)
CTA com label dinâmico refletindo o próximo obstáculo específico: [pancake-final § Transparência proativa antes do CTA]; padrão cross-fluxo do design system Kotai
Sinalização de risco in-place (aviso IL como atributo da posição, não popup separado): [uniswap-visualizar-pool.md § Insight — Sinalização de risco/variação in-place sem friction transacional]
CTA de comprometimento financeiro como primário brand (não verde de "validação"): [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência] + Pilar 3 Kotai — CTAs destrutivos nunca como primário verde; comprometimento financeiro segue o mesmo princípio
"Don't show this again" proibido para aviso de IL contextual: Pilar 7 Kotai — warnings de risco financeiro Tier 2 não têm dismiss permanente
Read-only estrito na revisão — toda edição obriga retorno à tela anterior: [uniswap-nova-posicao.md § Insight 3 — Feedback visual explícito de estado]; label "← Editar configuração" sinaliza consequência da ação antes do clique

🔴 Corrige

Custo total + breakdown visível antes do commit (gas de aprovação explicitado separadamente): deriva de [pancake-final § Insight — Transparência proativa antes do CTA] (fee total + breakdown explicitados antes do commit, incluindo gas de aprovação separado do gas de LP) e de [pancake-final § Pilar 4 — Educação contextual sistêmica + transparência financeira ativa] (linha-soma fechada de custo total como padrão do design system); reforçado por [uniswap-nova-posicao.md § Fricção 2 — Ausência de estado do pool destino na janela de decisão de aporte] (princípio: nenhuma informação financeira relevante oculta no fluxo de LP)
APR com decomposição de IL no ponto de maior tensão (não em docs externos): corrige [uniswap-visualizar-pool.md § Fricção — APR 0,00% mudo em fonte gigante] + [uniswap-final § Fricção 6 — Métricas DeFi sem decomposição]; APR sem IL é promessa falsa — na revisão final, é o último ponto em que o usuário pode calibrar expectativa antes de aportar
Mini-card de pool visível durante toda a revisão (contexto da entidade nunca perdido): corrige [uniswap-nova-posicao.md § Fricção 2 — Ausência de estado do pool destino na janela de decisão] e [uniswap-visualizar-pool.md § Fricção — Desacoplamento widget↔contexto da pool no ato de decidir]
Lembrete de par incompatível confirmado (sem nova fricção, apenas reforço): corrige o padrão de indústria de "aceitar e esquecer" — o usuário que confirmou "risco entendido" em T01/T03 deve ver um lembrete na revisão final; derivado de [pancake-adicionar-liquidez.md § Oportunidade 3 — Validação par↔protocolo inline antes do aporte]

🟡 Captura

Revisão financeira completa como tela dedicada (Step 3 do stepper): [uniswap-nova-posicao.md § Oportunidade 2 — Card de pré-visualização do pool destino antes do depósito] + [pancake-adicionar-liquidez.md § Fricção Estrutural 1 — Seleção de protocolo como caixa-preta sem pedagogia]. O Pancake não tem tela de revisão entre a seleção de filtro de pool e a execução — o usuário comete o aporte sem tela de checkpoint. O Uniswap tem o Continuar da Etapa 2, mas sem decomposição de custo. A Kotai entrega revisão explícita com custo e risco — diferencial de confiança para iniciante. Hipótese: usuário que vê custo total + aviso de IL antes do commit tem taxa de abandono menor por "surpresa de gas" e taxa de posição bem-formada maior.
Accordion de IL contextual (inline, não modal): [uniswap-visualizar-pool.md § Oportunidade — Narrativa automática dos dados em 3 níveis]. A narrativa narrativa de APR e IL integrada à tela de revisão — não acessível apenas via doc externo — diferencia a Kotai de todos os concorrentes analisados. Hipótese: iniciante que lê "quanto maior a divergência, maior a perda potencial" no momento de confirmação tem expectativa mais calibrada no primeiro mês de LP.

⚪ Novo

Linha de slippage com link "Ajustar →" que retorna para T02/T03 sem destruir o formulário: sem precedente explícito nos consolidados. Justificativa: o slippage foi configurado em T02/T03 e não deve ser re-exposto como campo editável em T04 (manteria o caráter read-only da revisão), mas o usuário avançado que chegou ao T04 e percebeu slippage inadequado precisa de um caminho de volta sem recomeçar. O link com retorno preservando contexto é o menor custo de implementação para o maior ganho de UX: previne re-submit com slippage errado. Custo: lógica de "retornar com scroll para slippage" em T02/T03 — baixa complexidade. Evidência a coletar: taxa de uso do link "Ajustar →" vs taxa de transações falhas por slippage insuficiente.
TTL de 60s para estimativa de gas com refresh manual: sem precedente nos consolidados. Justificativa: gas muda continuamente; mostrar dado stale sem indicação de idade gera expectativa frustrada quando o gas real divergir. O TTL + badge âmbar + refresh manual é o equilíbrio entre UX fluida e honestidade financeira. Custo: lógica de timestamp por fetch + badge condicional — trivial. Evidência a coletar: frequência de "gas real > estimativa" na revisão de transações falhas por gas insuficiente.

7. Trade-offs e Segunda Ordem

Tela adicional no fluxo: T04 é uma tela inteiramente nova entre configuração e execução — não existe equivalente explícito no Pancake nem no Uniswap como tela separada. O risco é atrito de "mais uma tela" que pode elevar abandono entre T03 e a execução. Mitigação: a tela é lean — poucos componentes, nenhuma decisão nova, CTA proeminente. O abandono por "surpresa de custo" (gas inesperado) ou "surpresa de risco" (IL desconhecido) após a execução é mais custoso ao produto do que abandono preventivo em T04.

Gas estimado vs real: A estimativa de gas em T04 é heurística — o gas real cobrado pela rede no momento de execução pode ser diferente. O label "~R$ XX,XX" e o sub-label "cobrado separadamente pela rede" sinalizam que é estimativa, não garantia. Risco residual: usuário com saldo de gas exatamente igual ao estimado pode falhar a transação. Mitigação: estimativa conservadora (pegar percentil 75 do gas estimado, não a mediana).

Accordion de IL: Mais conteúdo em tela já densa. Decisão de deixar colapsado por default (apenas "Entender o risco ▾" visível) reduz carga visual para o intermediário que já entende IL; o iniciante que precisar expandir tem o conteúdo disponível sem sair da tela. O accordion é colapsado por default — não expandido forçado — porque a presença do banner amarelo já cumpre o papel de sinalização; o texto detalhado é opt-in.

Dois banners simultâneos (pool inativa + IL para par volátil): Em pools inativas com par volátil, os dois banners co-existem na tela. Risco de "banner blindness" quando há dois avisos ao mesmo tempo. Hierarquia: pool inativa (vermelho, topo do bloco de parâmetros) tem prioridade visual sobre IL contextual (amarelo, abaixo do APR). O usuário pode ver ambos sem conflito — são riscos diferentes, não duplicados.

i18n: Accordion de IL + linha de slippage + nota de gas de aprovação = 6–8 strings adicionais por idioma. Custo de manutenção real quando novas moedas de rede forem adicionadas (gas em ETH/BNB/MATIC etc. exige strings diferentes). Mitigação: componente de card de custo com prop de "moeda de gas" — não hardcoded.

Portfolio-01 — Portfólio: visão geral sem ativos

1. Função da tela

Converter o momento de maior risco de abandono — wallet conectada, portfólio zerado — em instrução acionável para o primeiro aporte, priorizando o caminho mais curto e mais natural para o usuário iniciante BR/LatAm: PIX como porta de entrada financeira, "Receber de outra carteira" como alternativa imediata.

Perfil-foco: iniciante BR/LatAm (primary). Intermediário que já tem cripto em outro lugar também se beneficia, mas é usuário secundário desta tela.

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

Header patrimonial

Label: "Portfólio"
Valor principal: "R$0,00" (equivalente BRL, não USD; locale BR como default, alterável nas configurações)
Seletor de rede global: botão "Todas as redes" — DESABILITADO no estado vazio, com tooltip pedagógico "Disponível após o primeiro aporte"
Sub-label de contexto: endereço truncado "0xABCD…1234" + ícone de carteira conectada

Pills de período [1h / 1d / 7d / 30d / 1a / Tudo]

DESABILITADAS no estado vazio (chevron cinza, sem ação ao clicar), cada uma com tooltip "Disponível após o primeiro aporte"
Preservam modelo mental futuro sem gerar clique morto

Área do gráfico

Placeholder com borda tracejada — não skeleton pulsante (skeleton sugere conteúdo chegando; placeholder sinaliza "ainda não há dado")
Copy interna: "Seu histórico de patrimônio aparecerá aqui"

Cards de jornada (3 caminhos, empilhados verticalmente em mobile, grid 3 colunas em desktop)

Nomeados pela intenção do usuário, não pelo provider ou protocolo (Pilar 1)
Ordenação em mobile segue locale detectado: BR → PIX primeiro; outros locales → ordenação por adoção regional
Cada card: ícone + título de intenção + sub-label com detalhe de custo ou parceiros

Posição	Título	Sub-label BR
1º	"Comprar com fiat"	"via PIX · taxa est. 1,5%"
2º	"Receber de outra carteira"	"Transferência sem custo entre carteiras"
3º	"Trazer de uma exchange"	"De Mercado Bitcoin, Binance, Bitso e outras"

Sub-label não-BR do card 1: "Cartão de crédito ou débito · taxas variam" Sub-label não-BR do card 3: "De Coinbase, Binance e outras"

Tabs de navegação [Tokens / NFTs / Atividade]

Cada tab com URL própria: /portfolio/tokens, /portfolio/nfts, /portfolio/atividade
Estado ativo por default: tab Tokens

Tab Tokens — empty state

Search bar: DESABILITADA (sem borda de foco, cursor de proibido), tooltip "Disponível após adicionar tokens"
Instrução: "Adicione tokens para começar a acompanhar seu portfólio"
CTA alinhado à instrução: botão "Receber tokens" → abre Portfolio-03

Tab NFTs — empty state

Search bar: DESABILITADA, tooltip "Disponível após adicionar NFTs"
Instrução: "Adicione NFTs para acompanhar sua coleção"
CTA: botão "Receber NFTs" → abre Portfolio-03 variante NFT

Tab Atividade — empty state

Copy causal (não instrução — atividade não pode ser gerada diretamente desta tela): "Quando você fizer transações, elas aparecerão aqui"
Controles de filtro "Todos os tipos" e "Todo o período": DESABILITADOS com tooltip "Disponível após a primeira transação"
Sem CTA — estado correto; iniciar atividade requer ação em outro fluxo

Cosméticos (podem vir no segundo release)

Botão "Compartilhar portfólio" no header (visibilidade reduzida; sem sistema de referral ativo, não é prioridade — ver Observações adicionais do consolidado Uniswap sobre botão Compartilhar)
Avatar de identidade da carteira (ENS ou Jazzicon)

3. Regras de negócio

Seletor de rede:

Estado vazio: disabled. Tooltip único: "Disponível após o primeiro aporte". Não gera clique morto.
Estado populado: habilita automaticamente quando detecta saldo > 0 em qualquer rede.
Ao habilitar: mostra 3 seções — "Suas redes" (redes com saldo) / "Outras redes suportadas" / "Não suportadas nesta versão".
Label do botão muda ao selecionar rede específica: "Ethereum ✓" — nunca permanece "Todas as redes" com filtro ativo.

Pills de período:

Disabled em estado vazio. Habilitam quando histórico de patrimônio existe (≥ 1 transação detectada).
Estado selecionado: pill destacada com fundo preenchido; estado default é "7d".

Cards de jornada — detecção de locale:

Detecção via navigator.language + IP geolocalização (fallback para navigator.language se GeoIP indisponível).
Locale BR: card 1 mostra "via PIX · taxa est. 1,5%"; card 3 lista "Mercado Bitcoin, Binance BR, Bitso" no modal de seleção.
Locale não-BR: card 1 mostra "Cartão de crédito ou débito · taxas variam"; card 3 lista provedores regionais correspondentes.
Override disponível nas configurações do produto.

CTA da Tab Tokens → Portfolio-03:

Botão "Receber tokens" abre Portfolio-03 sem pré-seleção de token.
Botão "Receber NFTs" abre Portfolio-03 com filtro NFT ativo (ERC-721 / ERC-1155).
Após recebimento detectado on-chain → transition para Portfolio-02 com toast.

Propagação de estado:

Polling de 30s para detectar primeiro aporte on-chain.
Quando saldo > 0 detectado: toast "Primeiro aporte detectado!" + transição suave para Portfolio-02.
Estado vazio persiste até confirmação on-chain (não provisório no mempool).

4. Estados não-triviais

Vazio (estado principal desta tela)

Wallet conectada, portfólio zerado. Cards de jornada, tabs com empty states corretos, pills e seletor desabilitados.

Desconectado (sem wallet)

Versão simplificada: patriônio não exibido, área do header mostra "Conecte sua carteira para ver seu portfólio".
CTA primário: "Conectar carteira".
CTA secundário (link): "Primeira vez em cripto? Crie sua carteira →" (não CTA visual — é link de texto).
Cards de jornada: ocultos (A2 — não empilhar features irrelevantes para quem não tem wallet).
Tabs: visíveis mas com empty state genérico unificado "Conecte sua carteira para ver seus ativos".

Loading (carregando saldos on-chain após conexão)

Header: skeleton do valor patrimonial.
Cards de jornada: visíveis e clicáveis (funding independe de saldo carregado).
Tabs: skeleton da lista, NÃO full-screen overlay.
Pills e seletor: disabled (estado ainda indeterminado).
Copy de loading: "Carregando seu portfólio…" (discreta, não modal).

Erro (falha de RPC ou indexador)

Header: valor não exibido → "Dados temporariamente indisponíveis" com link "[Tentar novamente]".
Área do gráfico: placeholder cinza (não oculto) com copy "Dados do gráfico indisponíveis · [Tentar novamente]".
Cards de jornada: mantidos e clicáveis — funding não depende de estado de RPC.
Tabs: empty state declarativo com causa, não silêncio.

Erro parcial (EVM ok, Solana falhou)

Banner inline no topo da lista de ativos: "Não conseguimos carregar dados de [Solana]. Seu portfólio pode estar incompleto. [Tentar novamente]"
Patrimônio marcado com "~" e tooltip: "Estimativa parcial — dados de [Solana] indisponíveis".
Não bloqueia cards de jornada nem tabs EVM.

Sucesso (primeiro aporte detectado)

Toast: "Primeiro aporte detectado!"
Transição automática para Portfolio-02 após 1,5s.
NÃO muda a URL atual (transition in-place).

5. Microcopy crítico

Seletor de rede (tooltip disabled):

"Disponível após o primeiro aporte"

Pills de período (tooltip disabled):

"Disponível após o primeiro aporte"

Cards de jornada (locale BR):

Card 1: "Comprar com fiat" · "via PIX · taxa estimada 1,5%"
Card 2: "Receber de outra carteira" · "Transferência sem custo entre carteiras"
Card 3: "Trazer de uma exchange" · "De Mercado Bitcoin, Binance, Bitso e outras"

Tab Tokens — empty:

"Adicione tokens para começar a acompanhar seu portfólio" CTA: "Receber tokens" Tooltip disabled search: "Disponível após adicionar tokens"

Tab NFTs — empty:

"Adicione NFTs para acompanhar sua coleção" CTA: "Receber NFTs"

Tab Atividade — empty (copy causal, sem CTA):

"Quando você fizer transações, elas aparecerão aqui" Tooltip disabled filtros: "Disponível após a primeira transação"

Estado desconectado:

Título: "Acompanhe seu portfólio" Sub-título: "Conecte sua carteira para ver seus ativos" CTA primário: "Conectar carteira" Link secundário: "Primeira vez em cripto? Crie sua carteira →"

Estado de erro:

Header: "Dados temporariamente indisponíveis · [Tentar novamente]" Gráfico: "Dados do gráfico indisponíveis · [Tentar novamente]" Erro parcial banner: "Não conseguimos carregar dados de [rede X]. Seu portfólio pode estar incompleto. [Tentar novamente]" Patrimônio parcial: "~R$X.XXX,XX · estimativa parcial ⓘ"

Toast de sucesso:

"Primeiro aporte detectado!"

6. Rastreabilidade obrigatória

🟢 Herdado

Empty state convertido em instrução acionável — cards nomeados por fonte de origem do usuário ("de outra carteira", "de uma exchange"), CTA de tab alinhado à instrução da própria tab. [uniswap-portfolio § Insight — Empty state convertido em instrução acionável, telas 1–3]
Microcopy na linguagem mental do usuário — "Mercado Bitcoin, Binance, Bitso" (não "CEX"); "conta bancária via PIX" (não "Moonpay"); "de outra carteira" (não "deposit address"). [uniswap-portfolio § Insight — Microcopy na linguagem mental do usuário]
Copy causal na Tab Atividade ("Quando você fizer transações...") — reconhece que gatilho está em outro fluxo; NÃO simula instrução direta onde não há. [uniswap-portfolio § Insight — Declaração de erro/ausência > silêncio, tela 8]
Controles de descoberta visíveis — pills, seletor e search bar presentes no empty (modelo mental futuro) mas desabilitados (não geram clique morto). [uniswap-portfolio § Insight — Controles de descoberta visíveis, telas 2, 8–10]
URLs por tab — deeplink por tab correto (/portfolio/tokens, /portfolio/nfts, /portfolio/atividade). [uniswap-portfolio § Observação — Consistência URL por tab]
Jornada estruturada de 3 caminhos no empty — hierarquizados por frequência/facilidade para o target BR. [pancake-carteira-conectada § Insight — Empty state como jornada estruturada, tela 1]

🔴 Corrige

Affordances interativas ativas em estados onde não funcionam — pills de período clicáveis no empty (Uniswap): geram clique morto, erodem confiança. Corrige: disabled + tooltip pedagogíco, sem ocultar. [uniswap-portfolio § Fricção 1 — Affordances interativas ativas em estados onde não funcionam]
Gap entre instrução do empty state e CTA correspondente — Tab Tokens diz "Transfira tokens" mas não tem botão (Uniswap). Corrige: CTA "Receber tokens" alinhado à instrução da tab. [uniswap-portfolio § Fricção 3 — Gap entre instrução do empty state e CTA correspondente]
Exclusão geográfica nos pontos de entrada de funding — on-ramp global (Moonpay + Coinbase) sem alternativa local (Uniswap). Corrige: card 1 detecta locale BR e exibe PIX como default; card 3 lista provedores BR no topo. [uniswap-portfolio § Fricção — Exclusão geográfica nos dois pontos de entrada de funding]

🟡 Captura

On-ramp e CEX local-first detectados por geografia — PIX como default para locale BR, provedores BR no card de exchange; fee estimada exposta antes do clique. Pilar: Localização BR/LatAm como infraestrutura (Pilar 5). Hipótese: taxa de conversão de "clique no card de funding" para "primeira transação concluída" deve ser ≥ 2× maior que com on-ramp global, por eliminar o gate de KYC internacional e fee opaca. [uniswap-portfolio § Oportunidade — On-ramp e CEX local-first]
Error states com diagnóstico + ação — erro de RPC nomeia causa e entrega "[Tentar novamente]" imediato; erro parcial nomeia rede específica. Hipótese: converte "produto quebrado" em "problema localizado e endereçável". [uniswap-portfolio § Oportunidade — Error states com diagnóstico + ação]

⚪ Novo

Seletor de rede disabled no estado vazio com tooltip pedagógico: nenhuma concorrente resolve — Uniswap mantém ativo (clique morto). A Kotai desabilita mas preserva o elemento visualmente para criar o modelo mental antecipado. Justificativa: custo de 1 estado visual extra (disabled) compensa zero cliques mortos + zero confiança erodida. Evidência a coletar pós-lançamento: taxa de clique no seletor em estado vazio (indicador de confusão) vs. estado populado (indicador de uso real).
Polling de 30s para detecção de primeiro aporte: sem precedente direto nos consolidados. Justificativa: elimina necessidade de o usuário recarregar a página após o primeiro aporte (fricção oculta mas real); polling de 30s é custo de infraestrutura baixo para wallet com saldo zero. Evidência a coletar: latência média entre aporte confirmado on-chain e detecção pelo polling.

7. Trade-offs e segunda ordem

Dois estados visuais por componente (disabled / enabled):

Custo: desenvolvimento + testes para cada componente que tem estado vazio ↔ populado.
Mitigação: codificar disabled como token de design (cor, cursor, tooltip padrão) — um componente, não N correções pontuais.

Detecção de locale para on-ramp PIX:

Custo: manutenção de lista de provedores por jurisdição; VPN falseia locale → usuário vê PIX mas não está no Brasil. Fallback: se GeoIP falha, usar navigator.language. Se ambos falham, mostrar on-ramp global sem copy de taxa.
Risco regulatório: integração com PIX/on-ramp BR exige parceiros com licença de pagamento local.

Polling de 30s:

Custo de infraestrutura: chamadas de RPC para wallet recém-conectada com saldo zero. Aceitável — polling pode usar cache do indexador (não RPC direto) e parar após transição para Portfolio-02.

URLs por tab:

Exige roteamento client-side correto e metadados de OG por tab para compartilhamento social funcionar. Custo de engenharia baixo, mas deve estar no checklist de implementação.

Copy causal na Tab Atividade (sem CTA):

Risco: usuário sem CTA pode não saber como iniciar a primeira transação. Mitigado pelos cards de jornada no topo da tela, que são o ponto de entrada primário.

Adicionar Liquidez — Tela 05: Autorizar Tokens

1. Função da tela

Tela proativa de autorização de tokens — aparece entre T04 (revisão) e T06 (resultado) somente quando um ou ambos os tokens ainda não foram aprovados para o contrato LP da Kotai. Transforma uma etapa técnica opaca (token allowance) em sub-passo pedagógico nomeado e rastreável: o usuário sabe quantas autorizações são necessárias, quanto custa cada uma, e o que acontecerá quando todas estiverem completas. Foco: iniciante que interpreta a janela de aprovação da carteira como perda de tokens, e intermediário que quer confirmar o que está autorizando antes de assinar.

2. Componentes / Elementos

Estruturais (definem o paradigma da tela)

a) Stepper horizontal com sub-progresso "Par e modo" (✓) | "Configurar" (✓) | "Confirmar" (ativo — em andamento). O label "Confirmar" exibe um indicador de sub-passo discreto abaixo dele: "(Passo X de N)". Exemplo: se dois tokens precisam de aprovação e nenhum foi concluído: "(Passo 1 de 3)"; após primeira aprovação: "(Passo 2 de 3)"; após ambas: "(Passo 3 de 3)". A lógica de N é calculada no carregamento de T05: N = número de aprovações pendentes + 1 (a transação final de LP).

b) Barra de progresso de sub-passos (estrutural — âncora visual principal) Sequência horizontal de chips conectados por linha de progresso:

[✓ Par e modo]  ──  [✓ Configurar]  ──  [● Autorizar Token A]  ──  [○ Autorizar Token B]  ──  [○ Adicionar liquidez]

Chip ativo: círculo azul sólido com label. Chip pendente: círculo outline cinza com label. Chip completo: ✓ verde. Se apenas 1 token precisa de aprovação: a barra omite o chip do token já aprovado — mostra apenas os passos reais. Barra fica sticky abaixo do stepper principal.

c) Card de ação atual — Autorização (estrutural — conteúdo dinâmico por passo) O card muda conforme o sub-passo ativo. Três seções no card:

Seção 1 — O que está sendo autorizado:

Logo do token + nome do token + símbolo
Label: "Você está autorizando o contrato de liquidez da Kotai a movimentar [Token A] em seu nome."
Sub-label: "Esta autorização é necessária para o protocolo adicionar seus tokens ao pool. Você mantém controle — pode revogar quando quiser."

Seção 2 — Custo desta etapa:

"Gas desta autorização: ~R$ XX,XX"
Sub-label discreto: "Cada autorização é uma transação separada na rede."

Seção 3 — Status da carteira:

Estado "aguardando assinatura": ícone de carteira animado (pulse suave) + "Confirme esta autorização na sua carteira [nome da carteira]."
Estado "submetendo": spinner + "Autorização enviada — aguardando confirmação na rede."
Estado "confirmado": ✓ verde + "Autorizado com sucesso."

d) CTA principal — "Autorizar [Token A] na carteira" Label dinâmico com nome do token. Ao clicar, abre o modal de assinatura da carteira. Durante assinatura: CTA desabilitado com label "Aguardando assinatura...". Após assinatura: CTA desabilitado com label "Aguardando confirmação da rede...". Após confirmação on-chain: CTA transita automaticamente para o próximo sub-passo (sem clique adicional do usuário) ou para T06 se era o último passo.

e) Rodapé informativo — Gas total desta etapa Abaixo do card de ação, discreto: "Gas estimado desta etapa: ~R$ XX,XX · Você ainda pagará R$ YY,YY pelo aporte após as autorizações." Mantém o usuário informado do custo total, não apenas do sub-passo.

Cosméticos

Progress percentage numérico discreta abaixo da barra de sub-passos: "2 de 3 etapas concluídas"
Ícone de escudo pequeno ao lado da label de autorização — sinal de que esta é uma operação de permissão, não de perda
Timestamp da confirmação da autorização, quando confirmada: "Autorizado em HH:MM"
Link de explorer após submissão da autorização: "Ver transação →" (abre nova aba, não sai do fluxo)

3. Regras de Negócio

Condicionalidade: T05 só aparece se pelo menos um dos tokens precisar de aprovação para o contrato LP. Se nenhum token precisa de aprovação (já foram aprovados em sessão anterior para este contrato), o fluxo vai de T04 diretamente para T06, pulando T05. Verificação de allowance feita no carregamento de T04 (background, para não criar delay em T05).

Sequência de aprovações: Uma aprovação por vez — não solicitar assinatura de múltiplas aprovações simultaneamente. Token A primeiro, Token B segundo (ordem alfabética por símbolo ou pela ordem dos campos em T02/T03). Após confirmação on-chain de cada aprovação, o card atualiza automaticamente para o próximo token pendente.

Valor de aprovação: Aprovação pelo valor exato do aporte (não aprovação de "quantidade ilimitada" / uint256_max). Sub-label explicativo: "A autorização é limitada ao valor que você vai depositar agora — o protocolo não pode movimentar mais do que este montante." Justificativa: modelo de menor permissão, mais seguro para o usuário, e pedagogicamente correto para ensinar o que é uma aprovação.

Rejeição da assinatura: Se o usuário rejeitar a assinatura na carteira: card volta para o estado "aguardando assinatura" com nota âmbar: "Autorização cancelada. Toque em 'Autorizar' para tentar novamente." CTA reabilitado. Não retorna para T04 automaticamente — o usuário decide se tenta novamente ou usa "← Voltar à revisão".

Falha na rede: Se a transação de aprovação falhar on-chain (reverted): mensagem de erro específica no card + CTA "Tentar novamente" + link "Ver erro no explorador →". Não avança para próximo sub-passo.

Timeout de confirmação (> 3 minutos): Banner âmbar: "A confirmação está demorando mais que o usual — pode ser congestionamento na rede." Sub-label: "Você pode aguardar ou aumentar o gas e tentar novamente." Botão "Ver no explorador →" disponível. Não retorna para T04 automaticamente — a TX pode ainda confirmar.

Avanço automático: Após a última aprovação confirmada on-chain, T05 transita automaticamente para T06 com a execução da transação de LP. A transação de LP é submetida programaticamente sem novo clique do usuário — elimina a fricção de "clique para confirmar" após já ter clicado em "autorizar". O card de ação atualiza para mostrar a transição: "Autorizações concluídas · Adicionando liquidez..."

4. Estados Não-Triviais

Vazio (ao entrar em T05): Barra de sub-passos carregada. Card de ação mostrando o primeiro token pendente no estado "aguardando assinatura". CTA habilitado. Gas estimado visível.

Aguardando assinatura na carteira: CTA desabilitado com label "Aguardando assinatura...". Ícone de carteira animado no card. Se a carteira não abriu automaticamente (pop-up bloqueado em desktop): nota "Se a janela da carteira não abriu, clique no ícone da sua carteira."

Aprovação submetida (TX na rede): CTA desabilitado com label "Aguardando confirmação da rede..." + spinner. Hash da TX visível + link "Ver →". O chip do sub-passo atual mostra animação de loading.

Aprovação confirmada (avança para próximo): Chip do sub-passo atual muda para ✓ verde. Card de ação transita para o próximo token pendente com animação suave. Se era o último: card muda para "Autorizações concluídas · Adicionando liquidez..." + spinner da TX de LP.

Aprovação rejeitada (usuário cancelou na carteira): Banner âmbar no card: "Autorização cancelada. Toque em 'Autorizar' para tentar novamente." CTA reabilitado. Sem retorno automático para T04 — o usuário escolhe.

Aprovação falhou (TX revertida): Banner vermelho no card com mensagem específica. CTA "Tentar novamente" + link de explorer. Sub-label: "A autorização não foi registrada na rede — seus tokens não foram movidos."

Timeout (> 3 min): Banner âmbar: "Confirmação demorando mais que o usual." Link "Ver no explorador →". Sem retorno automático.

Todas as aprovações concluídas → transitando para LP: Card mostra estado de loading da TX de LP: "Adicionando liquidez..." + spinner. A barra de sub-passos atualiza para o chip "Adicionar liquidez" como ativo.

Navegação retroativa: Botão "← Voltar à revisão" disponível o tempo todo (exceto enquanto TX está submetida na rede). Retorna para T04 com todos os parâmetros preservados. Aprovações já confirmadas não precisam ser repetidas na próxima tentativa.

5. Microcopy Crítico

Título da tela:

"Autorizar tokens"

Breadcrumb:

"Ganhar rendimento / Adicionar liquidez / Autorizar"

Headline do card de autorização:

"Autorizar [Token A]"

Explicação de o que está sendo autorizado:

"Você está autorizando o contrato de liquidez da Kotai a movimentar [X,XXXX Token A] em seu nome." "Esta autorização é necessária para adicionar seus tokens ao pool. Você mantém controle total — pode revogar quando quiser."

Sub-label de valor limitado:

"A autorização é pelo valor exato do seu aporte — o protocolo não pode movimentar mais do que este montante."

Gas da aprovação:

"Gas desta autorização: ~R$ XX,XX" "Cada autorização é uma transação separada na rede."

Status aguardando assinatura:

"Confirme esta autorização na sua carteira [MetaMask / WalletConnect]"

CTA — aguardando:

"Autorizar [Token A] na carteira"

CTA — submetendo:

"Aguardando assinatura..."

CTA — confirmando na rede:

"Aguardando confirmação da rede..."

Após aprovação confirmada:

"✓ [Token A] autorizado"

Barra de sub-passos — labels:

"Autorizar [Token A]" / "Autorizar [Token B]" / "Adicionar liquidez"

Progresso numérico:

"Etapa 1 de 3 concluída"

Rodapé de custo total:

"Gas total desta etapa: ~R$ XX,XX · Você ainda pagará ~R$ YY,YY pelo aporte"

Link de explorer:

"Ver transação →"

Pop-up não abriu:

"Se a janela da carteira não abriu, clique no ícone da sua carteira no navegador."

Rejeição do usuário:

"Autorização cancelada. Toque em 'Autorizar' para tentar novamente."

Falha de rede:

"A autorização não foi registrada na rede. Seus tokens não foram movidos." [Tentar novamente] [Ver erro no explorador →]

Timeout:

"A confirmação está demorando mais que o usual — pode ser congestionamento na rede." [Aguardar] [Ver no explorador →]

Transição para LP após aprovações:

"✓ Autorizações concluídas · Adicionando liquidez..."

Botão de retorno:

"← Voltar à revisão"

6. Rastreabilidade Obrigatória

🟢 Herdado

Aprovação como passo proativo nomeado do fluxo (não erro de recuperação): padrão estabelecido em criar-pool-04 do design system Kotai; referenciado em adicionar-liquidez-02 e adicionar-liquidez-03 como comportamento prometido
Stepper preservado durante sub-passos de confirmação: [uniswap-nova-posicao.md § Insight 1 — Stepper pedagógico e contextual]; o stepper não "some" durante aprovações — a progressão do fluxo maior permanece visível
CTA com label dinâmico que nomeia o que acontecerá: [pancake-final § Transparência proativa antes do CTA]; "Autorizar [Token A] na carteira" nomeia o token e a ação exatos
Cobertura explícita de estados não-triviais (submetido / confirmado / rejeitado / falhou / timeout): [pancake-final § Cobertura proativa de estados não-triviais]; estado não enumerado = estado que vira bug em produção
Link de explorer disponível após submissão: [uniswap-visualizar-pool.md § Insight — Dados on-chain inline sem desvio para explorer externo]; princípio simétrico: quando a TX está no explorer, o link pertence à tela
Não avançar automaticamente após rejeição do usuário — exigir ação explícita: [pancake-final § Pilar 3 — Defesa em camadas + Hierarquia de toggle]; cancelamento é sinal de incerteza — não redirecionar silenciosamente

🔴 Corrige

Gas de aprovação visível separadamente do gas de LP: deriva de [pancake-final § Insight — Transparência proativa antes do CTA] (gas total e breakdown explicitados antes do commit como padrão de transparência financeira) e de [pancake-final § Pilar 4 — Educação contextual sistêmica + transparência financeira ativa]; o usuário precisa saber que aprovações custam gas separado antes de gastar — não depois de ver o saldo de gas mais baixo que o esperado
Explicação de o que é aprovação em linguagem de usuário (não jargão técnico): corrige [pancake-final § Fricção 1 — Léxico de protocolo como vocabulário primário]; "token allowance" e "approve()" são jargão de Solidity, não linguagem do usuário
Rejeição pelo usuário com recovery explícito (não retorno automático silencioso): corrige [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência]; ação de cancelamento tem consequência que o sistema deve nomear, não tratar como estado vazio

🟡 Captura

Autorização pedagógica no ponto de decisão: derivado de [pancake-final § Pilar 4 — Educação contextual + Transparência financeira] e [uniswap-nova-posicao.md § Insight 2 — Microcopy pedagógica inline]. O iniciante que entende "o protocolo pode mover exatamente X tokens e não mais" tem modelo mental correto de segurança de DEX — diferencial de confiança sobre concorrentes que mostram a janela de aprovação sem contexto. Hipótese: taxa de abandono durante aprovação ("achei que ia perder os tokens") cai com copy explicativo antes da janela da carteira.
Barra de sub-passos com previsão do fluxo completo: derivado de [uniswap-nova-posicao.md § Insight 1 — Stepper pedagógico] aplicado ao nível de sub-passo. Nenhum DEX analisado exibe a sequência de aprovações + LP como progresso visual antes de começar. Hipótese: usuário que sabe "são 3 etapas e estou na 1ª" não abandona na 2ª aprovação por acreditar que o processo não termina.

⚪ Novo

Aprovação pelo valor exato do aporte (não uint256_max): sem precedente nos consolidados como opção de UX documentada explicitamente. O princípio âncora é [pancake-final § Pilar 3 — Defesa em camadas] (Pilar 3 Kotai — menor permissão por default é mais seguro; o template de Expert Mode mostra que a Pancake aplica defesa em camadas, mas não generalizou para aprovações de token), porém a decisão específica de expor aprovação por valor exato como UX principal é nova — nenhum dos concorrentes analisados documenta esta opção como padrão. Justificativa: aprovação ilimitada é padrão de indústria por conveniência (o usuário não precisa aprovar de novo na próxima operação), mas cria surface area de segurança desnecessária. Para o target iniciante da Kotai, a conveniência de "não precisa aprovar de novo" é menos valiosa do que a garantia de "o protocolo só move o que você autorizou agora". O custo é uma aprovação adicional na próxima operação com o mesmo par. Evidência a coletar: taxa de reclamações de segurança relacionadas a aprovações ilimitadas vs taxa de abandonos por "ter que aprovar de novo". Decisão revisável por release.
Avanço automático para a TX de LP após última aprovação (sem clique adicional): sem precedente explícito nos consolidados. Justificativa: após confirmar o aporte em T04 e autorizar os tokens em T05, o usuário já tomou duas decisões conscientes de comprometimento financeiro. Exigir um terceiro clique "Confirmar aporte" após as aprovações é fricção redundante (A3 — solução pior que o problema). O avanço automático é a execução do que o usuário já autorizou. Custo: lógica de trigger condicional após última aprovação — trivial. Risco residual: se o usuário mudou de ideia durante as aprovações, não tem janela de saída antes da TX de LP. Mitigação: botão "← Voltar à revisão" visível durante o estado "Aguardando confirmação" da aprovação — janela de escape disponível até a TX de LP ser submetida. Evidência a coletar: taxa de uso de "← Voltar à revisão" durante T05 como proxy de "mudança de ideia durante aprovações".
Barra de sub-passos omitindo chips de tokens já aprovados: sem precedente nos consolidados. Justificativa: exibir um chip "Autorizar Token A (já aprovado)" marked out confunde mais do que informa — o usuário não sabe se precisa fazer algo ou não. A barra mostra apenas os passos reais restantes. Custo: lógica de construção dinâmica da barra baseada em allowance real, não em template fixo. Evidência a coletar: taxa de confusão ("por que só vejo 1 autorização quando esperava 2?") via suporte.

7. Trade-offs e Segunda Ordem

Aprovação por valor exato: Cria dívida de UX para operações futuras — na próxima vez que o usuário adicionar liquidez com o mesmo par, precisará aprovar novamente se o valor for diferente. Concorrentes que usam uint256_max eliminam essa fricção futura. Mitigação de segunda ordem: ao aprovar, oferecer ao usuário avançado um toggle "Aprovação estendida (não precisar aprovar de novo)" — mas defaultar no valor exato para o iniciante. Esse toggle seria Tier 2 (preferência) na hierarquia de toggles do Pilar 3.

Avanço automático após aprovações: Se o usuário tiver mudado de ideia (ex: o preço do token mudou significativamente entre T04 e o final de T05), não terá janela de confirmação adicional antes da TX de LP. Mitigação: botão "← Voltar à revisão" disponível durante a confirmação das aprovações. Aceitar o risco residual — a TX de LP com parâmetros previamente revisados em T04 é o comportamento correto; o usuário que quiser mudar de ideia tem o escape disponível.

Barra de sub-passos em mobile: em viewport estreito (< 375px), chips de sub-passo podem ser muito densos. Mitigação: em mobile, exibir apenas o chip ativo como texto ("Passo 2 de 3: Autorizar [Token B]") sem a linha completa de chips conectados. A versão completa da barra aparece apenas em desktop e tablets.

Gas por aprovação vs gas real: Estimativa de gas para aprovação de token varia por contrato (ERC-20 com lógica adicional como fee-on-transfer pode ter gas mais alto). Mitigação: estimativa conservadora (percentil 90 do gas de approve() para os contratos conhecidos) com label "~R$" sinalizando estimativa. Contratos desconhecidos (tokens importados por endereço): fallback "Gas estimado: variável — depende do contrato do token."

i18n: 12–15 strings dinâmicas (token name, valor, gas em R$, número de etapas). Componente de card de autorização com props de conteúdo — não hardcoded. Moeda de gas varia por rede (R$ com ETH/BNB/MATIC como denominador), exigindo oracle de preço disponível para cada rede ativa.

Portfolio-02 — Portfólio: visão geral com ativos

1. Função da tela

Dar ao usuário com ativos uma visão clara e honesta do que tem — distinguindo o valor declarado pelo mercado do valor efetivamente realizável (saída estimada) — com drill-down por rede e por tipo de ativo, sem agregar números que escondem escopo nem exibir affordances que não funcionam.

Perfil-foco: iniciante e intermediário. Iniciante precisa da honestidade sobre liquidez; intermediário multi-chain precisa do seletor de rede com hierarquia útil.

2. Componentes / elementos

Estruturais (definem o paradigma da tela)

Header patrimonial dual

Grandeza primária (fonte maior): "Patrimônio declarado · R$X.XXX,XX"
Grandeza secundária (fonte menor, cor secundária): "Saída estimada · ~R$X.XXX,XX ⓘ"
- Tooltip do ⓘ: "Se vendesse todos os ativos agora, com base nas rotas de melhor preço disponíveis. Pode diferir do declarado em ativos com baixa liquidez."
Sub-label temporal: "Atualizado às [HH:MM] · [Atualizar]" (timestamp do último snapshot)
Seletor de rede global: ATIVO (com saldo, diferente de Portfolio-01)
- Label default: "Todas as redes ([N] com saldo)"
- Label ao selecionar: "Ethereum ✓" — nunca permanece "Todas as redes" com filtro ativo

Seletor de rede — 3 seções internas (ao abrir o dropdown)

"Suas redes" — redes onde o usuário tem saldo, ordenadas por valor decrescente, saldo inline por rede ("Ethereum · R$1.234,00")
"Outras redes suportadas" — redes suportadas sem saldo do usuário, sem valor inline
"Não suportadas nesta versão" — lista mínima de redes populares ausentes ("Avalanche · não suportada nesta versão"), sem valor, com copy neutra

Redes da seção 3 são curadas manualmente (revisão trimestral); lista pequena evita percepção de cross-promo negativa

Pills de período [1h / 1d / 7d / 30d / 1a / Tudo] — ATIVAS

Estado selecionado por default: "7d" (default contextual; wallet > 30d de existência: "30d")
Ao selecionar rede específica: header muda para "Patrimônio em [Ethereum] · R$X.XXX,XX"

Gráfico de patrimônio

Dado padrão: Patrimônio declarado (linha única)
Toggle opcional: "Mostrar saída estimada" como segunda linha no gráfico (opt-in, OFF por default — evita poluição visual no caso padrão)
Tap-and-stick em mobile (não hover-only) — Pilar 5

Tabs de navegação [Tokens / NFTs / Atividade]

URLs: /portfolio/tokens, /portfolio/nfts, /portfolio/atividade
Tab ativa default: Tokens

Tab Tokens — lista de ativos

Search bar: ATIVA (no estado populado, sempre ativa)
Cada linha de token:
- Ícone token + nome (não contrato)
- Badge de rede(s) onde o usuário tem o token (ex: "ETH" pode aparecer em Ethereum + Base)
- Saldo em quantidade + equivalente BRL (linha 1)
- Valor declarado: R$XXX,XX
- Segunda linha condicional (só exibida quando saída estimada difere > 5% do declarado): "Saída estimada · ~R$XX ⓘ · liquidez limitada pelo pool"
  - Tooltip: "Estimativa de quanto você receberia ao vender agora, via melhor rota disponível"
- Copy neutra — nunca "shitcoin", nunca julgamento implícito; "liquidez limitada pelo pool" é factual
Ordenação: por valor declarado decrescente (default)
Controles de ordenação: collapse/expand — não expostos por default; "Ordenar por ▾" ao toque abre bottom sheet com opções

Tab NFTs — lista de coleções

Sem valor monetário principal — NFT não tem preço fungível (replicar decisão do Uniswap de não forçar US$ em NFT)
Organização por coleção (não por item individual no estado padrão)
Search bar ativa
Cada coleção: ícone + nome + count de itens + rede

Tab Atividade — lista de transações

Filtros ativos: "Todos os tipos ▾" e "Todo o período ▾"
- "Todos os tipos": 11 categorias agrupadas em 4 macros: Negociações (Swap, Ordem Limite) / Liquidez (Adicionar, Remover) / Movimentação (Enviar, Receber, Ponte) / Sistema (Aprovação, Remoção de aprovação, Contrato, Outro)
- "Todo o período" default OK para wallet nova; wallet com > 90d de atividade: default muda para "30d" automaticamente (default contextual — Pilar 2)
- Filtros são multi-select (não radio) — bloco de auditoria fiscal exige combinações como "Swap + Receber"
Linha de transação: ícone de tipo (↑ Enviar / ↓ Receber / ⇄ Swap / + Adicionar / − Remover) + descrição + valor + timestamp relativo + chevron ▸ para expandir detalhes em mobile
Search bar ativa (quando há histórico)

Cosméticos (segundo release)

Botão "Exportar dados" na Tab Atividade → gera CSV com transações filtradas (base para exportação fiscal futura)
Avatar ENS ou Jazzicon no header
Sparkline de 7d inline por token na lista (micro-chart — adição futura)

3. Regras de negócio

Seletor de rede — label ao selecionar:

"Todas as redes ([N] com saldo)" → nenhuma rede específica selecionada
"[Nome da Rede] ✓" → rede específica selecionada (nunca permanece texto genérico)
Seletor filtra: patrimônio total + gráfico + Tab Tokens + Tab NFTs + Tab Atividade simultaneamente
Ao filtrar por rede: header muda para "Patrimônio em [Ethereum]" com badge de scope; pills de período preservadas

Segunda linha de token (saída estimada):

Threshold: exibe somente quando saída_estimada < declarado * 0,95 (diferença > 5%)
Cálculo: rota de melhor preço via routing engine do produto (não chamada de RPC em tempo real por token; usar cache de 5 minutos)
Estado stale (cache > 10 minutos): badge "⚠ estimativa desatualizada" na segunda linha; não exibir valor stale como verdade
NÃO exibida para tokens com valor declarado < R$1,00 (ruído vs. benefício não justifica cálculo)

Patrimônio declarado vs saída estimada no header:

"Saída estimada" do header = soma das saídas estimadas por token (aproximação)
Pode ser imprecisa para portfólios com muitos tokens — tooltip declara isso explicitamente
NÃO exibir saída estimada no header quando > 30% dos tokens não têm cálculo disponível → trocar por "Saída estimada indisponível · parte do portfólio sem liquidez calculada"

Default de período por maturidade da wallet:

Wallet com < 30d de atividade on-chain: default "7d"
Wallet com ≥ 30d de atividade: default "30d"
Aplicado na Tab Atividade. Pills de período do header patrimonial: sempre default "7d" (visualização de ganho de curto prazo)

Seleção de rede — curadoria "Não suportadas":

Lista curada manualmente, revisada trimestralmente pelo produto
Máximo 10 redes nesta seção (evitar lista interminável)
Copy padrão por item: "[Nome da Rede] · não suportada nesta versão" — sem prazo comprometido

4. Estados não-triviais

Populado (estado principal desta tela)

Saldo detectado em ≥ 1 rede. Header dual ativo, tabs populadas, seletor com conteúdo.

Loading de atualização de preços (preços sendo refrescados)

Valor declarado antigo permanece visível — NÃO full-screen skeleton
Spinner discreto ao lado do valor (não sobreposto ao número)
Toast discreto: "Atualizando preços…" — desaparece ao completar
Tabs e seletor permanecem interativos durante update de preço

Erro de preço de token específico

Token afetado: badge "⚠ Preço indisponível" no lugar do valor declarado
Patrimônio total: marcado com "~" + tooltip "Estimativa — preço de [token X] indisponível"
NÃO bloqueia o restante da interface

Erro de gráfico

Widget do gráfico: área cinza com copy declarativa "Dados do gráfico temporariamente indisponíveis · [Tentar novamente]"
NÃO ocultar o widget — preserva o slot, declara o que faltou
Pills de período permanecem visíveis mas clique nelas mostra toast "Aguarde, dados do gráfico indisponíveis"

Seleção de rede sem saldo

Usuário seleciona rede da seção "Outras redes suportadas" → portfólio mostra "Nenhum ativo em [Ethereum]" com CTA "Receber ativos em Ethereum" → abre Portfolio-03 com rede pré-selecionada
NÃO empty state genérico — contextualiza qual rede está vazia

Portfólio com 1 token apenas (saída estimada = declarada)

Segunda linha não exibida para este token (diferença ≤ 5%)
Header: saída estimada igual ao declarado → pode omitir a grandeza secundária ou exibir "Saída estimada · ~R$X.XXX,XX ≈ declarado"

Saída estimada indisponível (> 30% dos tokens sem liquidez calculada)

Grandeza secundária do header substituída por: "Saída estimada · parcialmente disponível ⓘ"
Tooltip: "Não foi possível calcular a saída estimada para parte do portfólio. Valores de liquidez limitada não estão incluídos."

Filtro de atividade retorna zero resultados

Copy: "Nenhuma transação corresponde aos filtros selecionados. Você tem [N] transações no histórico completo. [Ver todas]"
NÃO o mesmo empty state de "sem histórico" — distinção obrigatória

5. Microcopy crítico

Header patrimonial:

Grandeza primária: "Patrimônio declarado"
Grandeza secundária: "Saída estimada ⓘ"
Tooltip ⓘ: "Se vendesse todos os ativos agora, com base nas rotas de melhor preço disponíveis. Pode diferir do declarado em ativos com baixa liquidez."
Sub-label temporal: "Atualizado às [HH:MM] · [Atualizar]"

Seletor de rede:

Default: "Todas as redes ([N] com saldo)"
Selecionado: "[Nome da Rede] ✓"
Seções internas: "Suas redes" / "Outras redes suportadas" / "Não suportadas nesta versão"
Item não suportado: "[Nome da Rede] · não suportada nesta versão"

Segunda linha de token (liquidez limitada):

"Saída estimada · ~R$XX ⓘ · liquidez limitada"
Tooltip ⓘ: "Estimativa de quanto você receberia ao vender agora, via melhor rota disponível. Liquidez limitada significa que há poucos compradores para este ativo."

Header com filtro de rede ativo:

"Patrimônio em Ethereum · R$X.XXX,XX"
Badge de scope: "Ethereum ✓" no botão de rede

Erro de gráfico:

"Dados do gráfico temporariamente indisponíveis · [Tentar novamente]"

Erro de preço de token:

Badge no token: "⚠ Preço indisponível"
Header com token afetado: "~R$X.XXX,XX · estimativa parcial ⓘ"

Empty state de rede selecionada sem saldo:

"Nenhum ativo em [Ethereum]"
CTA: "Receber ativos em Ethereum"

Filtro de atividade com zero resultados:

"Nenhuma transação corresponde aos filtros. Você tem [N] transações no histórico completo. [Ver todas]"

Estimativa indisponível (> 30% sem cálculo):

"Saída estimada · parcialmente disponível ⓘ"
Tooltip: "Não foi possível calcular a saída estimada para parte do portfólio."

6. Rastreabilidade obrigatória

🟢 Herdado

Controles de descoberta ATIVOS quando há conteúdo — search bar, filtros e pills habilitados quando o portfólio tem dados. Mesma lógica de Portfolio-01 (disabled no vazio), invertida para o estado populado. [uniswap-portfolio § Insight — Controles de descoberta visíveis, telas 2, 8–10]
Widget cinza + copy declarativa em erro de gráfico — NÃO ocultar, NÃO silenciar. Declara o que faltou. [uniswap-portfolio § Insight — Declaração de erro/ausência > silêncio, tela 5]
URLs por tab — deeplink funcional por seção do portfólio. [uniswap-portfolio § Observação — Consistência URL por tab]
Ausência de valor monetário na Tab NFTs — NFT não tem preço fungível; forçar US$ seria ficção contábil. [uniswap-portfolio § Insight — Decisão correta tela 7]
Tap-and-stick no gráfico (mobile) — interação de scrub via toque, não hover. [pancake-final § Pilar 5 — Mobile-first interaction]
Default contextual por maturidade de wallet — "7d" para nova, "30d" para madura (≥ 30d). [uniswap-final § Pilar 2 — CTA dinâmico + Default contextual] [uniswap-portfolio § Fricção — default Todo o período inadequado para wallet madura, tela 10]

🔴 Corrige

Agregações sem escopo declarado — label "Todas as redes ([N] com saldo)" declara escopo; label muda ao selecionar rede específica; seção "Suas redes" separa o que tem saldo do que não tem. [uniswap-portfolio § Fricção 2 — Agregações sem escopo declarado]
Seletor de rede ambíguo e sem feedback de estado — label muda ao selecionar rede (nunca permanece "Todas as redes" com filtro ativo); header reflete rede selecionada. [uniswap-portfolio § Fricção — Seletor de rede ambíguo e sem feedback de estado, tela 11]
Default "Todo o período" inadequado para wallet madura — default contextual por maturidade resolve sem sacrificar UX de wallet nova. [uniswap-portfolio § Fricção — Filtro temporal sem date picker, tela 10]
Filtro de tipos provavelmente radio — implementado como multi-select (não radio), habilitando combinações fiscais. [uniswap-portfolio § Fricção — filtro de tipos radio, tela 9]

🟡 Captura

Portfólio com valor recuperável vs valor declarado — duas grandezas no hero (Patrimônio declarado + Saída estimada), segunda linha de token para ativos com liquidez limitada. Pilar 4 (Transparência financeira). Hipótese de diferenciação: usuário ajusta expectativa antes de tentar vender, reduzindo frustração com slippage alto; "saída estimada" como conceito educacional que distingue valor de tela de valor realizável — sem precedente em DEX. [uniswap-portfolio § Oportunidade — Portfólio com valor recuperável vs declarado]
Seletor de rede contextualizado com escopo declarado — 3 seções (Suas redes / Outras suportadas / Não suportadas), redes da seção 1 ordenadas por valor com saldo inline. Hipótese: intermediário multi-chain encontra suas 2-3 redes principais no topo sem rolar lista de 18+; iniciante vê de imediato que "Avalanche" não está disponível (evita tentativa de depositar em rede não suportada). [uniswap-portfolio § Oportunidade — Seletor de rede contextualizado]

⚪ Novo

Grandeza dual no hero (Patrimônio declarado + Saída estimada): a distinção existe na oportunidade dos relatórios, mas a implementação como duas grandezas co-visíveis no hero é decisão de layout nova. Nenhuma concorrente analisada expõe isso. Risco: usuário pode ficar ansioso ao ver diferença grande entre declarado e recuperável para tokens illíquidos. Mitigação: copy neutra ("liquidez limitada pelo pool") sem julgamento de valor; toggle para ocultar saída estimada disponível nas configurações. Evidência a coletar pós-lançamento: taxa de clique no ⓘ de saída estimada (curiosidade) vs. taxa de abandono da tab após exibição de diferença grande.
Agrupamento de categorias de atividade em 4 macros (Negociações / Liquidez / Movimentação / Sistema): o consolidado identifica as 11 categorias sem agrupamento como fricção, mas não prescreve os macros. Esta estrutura deriva da lógica fiscal (DARFs no Brasil segmentam atividades de forma similar). Justificativa: 11 itens em lista plana = scan de 11 linhas; 4 macros = scan de 4 cabeçalhos + expansion. Evidência a coletar: uso de filtros agrupados vs. itens individuais.

7. Trade-offs e segunda ordem

Cálculo de saída estimada (custo de RPC + routing):

Cache de 5 minutos por token por rede mitiga custo de RPC.
Para portfólios com > 20 tokens, calcular em background (não bloquear carregamento da tela).
Tokens de cauda longa (TVL < $10k) podem gerar estimativas imprecisas — threshold de exibição (diferença > 5% + token com saldo > R$1) reduz ruído.
O risco político de classificar tokens como "ilíquidos" é real — copy neutra ("liquidez limitada pelo pool") foca no dado objetivo, não no julgamento do token.

Seletor de rede "Não suportadas":

Curadoria manual tem custo recorrente. Lista máxima de 10 evita manutenção excessiva.
Risco de leitura como endosso negativo ("Kotai acha que Avalanche é ruim"). Mitigar com copy neutra "não suportada nesta versão" — sem prazo implícito.

Duas grandezas no hero:

Dois números competindo por atenção pode confundir iniciante absoluto.
Hierarquia de tamanho (declarado grande / estimado pequeno) resolve em 90% dos casos.
Toggle para ocultar saída estimada nas configurações garante escape para quem prefere visão simples.

Filtros multi-select na Tab Atividade:

Estado "qual combinação está ativa" mais difícil de comunicar que radio.
Badge de count "[N] filtros ativos" no botão do dropdown resolve: "Todos os tipos (3 ▾)" quando não-default.
Mais estado de componente = mais testes de QA necessários.

Default contextual por maturidade de wallet:

Requer leitura on-chain de data da primeira transação.
Se dado indisponível: fallback para "7d" (padrão conservador que não assume histórico).

Adicionar Liquidez — Tela 06: Transação em Andamento e Resultado

1. Função da tela

Tela de feedback pós-submit — cobre todos os estados após a transação de LP ter sido enviada à rede: pendente (aguardando confirmação on-chain), sucesso (posição criada com resumo e próximas ações) e erro (falha diagnosticada com recovery específico). Funciona como encerramento narrativo do fluxo de 6 telas: do par selecionado em T01 à posição confirmada em T06. Foco: iniciante que precisa saber se "funcionou" sem interpretar mensagens técnicas de blockchain; intermediário que quer o hash da TX, link de explorer e o estado final da posição.

2. Componentes / Elementos

Estruturais por estado — o componente principal muda conforme o estado da TX

Estado A: Pendente (TX enviada, aguardando confirmação on-chain)

a) Stepper horizontal — finalizado "Par e modo" (✓) | "Configurar" (✓) | "Confirmar" (em andamento — spinner discreto). O stepper permanece visível e comunica: "o processo não acabou, mas está no último passo."

b) Indicador visual de progresso — hero component Animação circular de loading com os dois avatares de token sobrepostos no centro (mesmo ícone combinado de par do mini-card). Cor: azul brand em progressão circular (não spinner genérico — é o par do usuário).

c) Headline e sub-headline Headline: "Registrando sua posição..." Sub-headline: "Sua transação foi enviada — aguardando confirmação na rede [Nome da Rede]."

d) Card de transação

Hash truncado da TX: 0xAB12...CD34 com ícone de cópia ⬡ e link "Ver no explorador →" (abre nova aba)
Status: "Aguardando confirmação" + indicador de "N blocos confirmados de M necessários" quando disponível
Gas pago: "Gas pago: R$ XX,XX" (gas real já cobrado, diferente do estimado — exibe a diferença se > 5%)

e) Contexto pedagógico de blockchain (colapsado por default, accordion "Saiba mais ▾") "Transações em blockchain são processadas em blocos — cada bloco leva ~12 segundos no Ethereum, ~3 segundos na BNB Chain. Em períodos de congestionamento, pode levar mais tempo." Não exibir forçado — é complementar para quem está curioso, não obrigatório para completar o fluxo.

f) Ação disponível durante pendência Link discreto (não CTA proeminente): "Você pode fechar esta tela. Sua transação continuará sendo processada. [Ver no explorador →]" Sub-label: "Sua posição aparecerá em 'Minhas posições' assim que confirmada."

Estado B: Sucesso (posição criada)

a) Stepper horizontal — concluído "Par e modo" (✓) | "Configurar" (✓) | "Confirmar" (✓). Todos verdes.

b) Feedback visual de sucesso — hero component Ícone de sucesso animado (✓ verde com expansão suave) + ícone combinado de par. Sem confetes excessivos — produto financeiro exige seriedade, não celebração de gamificação. Efeito discreto de pulse verde.

c) Headline

"Posição criada com sucesso"

d) Card de resumo da posição criada (estrutural — dados da posição real)

Par + modo (label de benefício, não nome técnico): "USDC/ETH · Concentrada em um intervalo"
Valores aportados: "X,XXXX USDC + X,XXXX ETH (≈ R$ X.XXX,XX total)"
Para modo Concentrada: "Faixa: R$ XX,XX – R$ YY,YY · Preset: Equilibrado"
APR estimado: "~X,X% ao ano (estimativa 30d, sem IL) ⓘ" — mesmo caveat obrigatório do fluxo
Status in-range (Concentrada): badge verde "● In-range" ou badge âmbar "● Fora da faixa" se o preço saiu durante o processamento
ID da posição (V3/V4): "#NNNN" — discreto, não hero
Gas total pago: "Gas total: R$ XX,XX (aprovações + aporte)"

e) CTAs de continuidade (hierarquia clara)

CTA primário: "Ver minha posição →" — navega para visualizar-posicao passando o ID da posição criada
CTA secundário: "Adicionar mais liquidez" — retorna para T01 com o par pré-selecionado (reutiliza o contexto)
Link terciário: "Voltar ao início" — sem destaque visual; para quem finalizou a jornada

f) Link de explorer "Ver transação confirmada →" — abaixo do card de resumo, discreto. Não CTA.

Estado C: Erro (TX falhou)

a) Feedback visual de erro — hero component Ícone de erro (× vermelho, não animado — erros não são celebrados) + ícone do par.

b) Headline + diagnóstico específico Headline e sub-headline variam por tipo de erro:

Slippage excedido:

"Transação não executada — slippage excedido" "O preço mudou mais do que sua tolerância de slippage (X,X%) enquanto a transação estava na rede. Seus tokens não foram movidos."

Gas insuficiente (TX revertida por falta de gas):

"Transação não executada — gas insuficiente" "A transação precisou de mais gas do que o estimado. Seus tokens não foram movidos."

TX revertida (outro motivo):

"Transação revertida pelo protocolo" "O protocolo não conseguiu executar o aporte. Seus tokens não foram movidos."

Usuário cancelou na carteira:

"Transação cancelada" "Você cancelou a transação na carteira. Seus tokens não foram movidos."

Timeout (TX não confirmada em X minutos):

"Transação sem confirmação" "A transação está demorando mais que o esperado — pode ter ficado pendente na rede. Verifique no explorador."

c) Card de recovery contextual (cada tipo de erro tem ação específica)

Slippage excedido → ação contextual:

"Tolerância atual: X,X% · Sugerimos aumentar para Y,Y% para este pool"
CTA primário: "Tentar novamente com slippage maior" — retorna para T04 com slippage pre-ajustado
Link secundário: "Voltar à revisão com configuração atual"

Gas insuficiente → ação contextual:

"Gas estimado: R$ XX,XX · Gas real necessário: R$ YY,YY"
CTA primário: "Comprar [ETH / BNB] para gas →" — abre on-ramp contextual para a moeda de gas
Link secundário: "Tentar novamente (gas pode ter variado)"

TX revertida → ação contextual:

Link "Ver erro técnico no explorador →" para quem quer investigar
CTA primário: "Tentar novamente" — retorna para T04 com os parâmetros preservados
Link secundário: "Falar com suporte" (para casos onde o retry não resolve)

Usuário cancelou → ação contextual:

CTA primário: "Retomar aporte" — retorna para T04 com todos os parâmetros preservados
Link secundário: "Abandonar — voltar ao início"

Timeout → ação contextual:

"Sua transação ainda pode confirmar — verifique no explorador antes de tentar novamente para evitar aporte duplo."
CTA primário: "Ver transação no explorador →" (abre nova aba, não sai da tela)
Link secundário: "Tentar novamente" (com aviso inline: "Certifique-se de que a transação anterior não confirmou")

d) Garantia de não-perda de fundos Para todos os tipos de erro exceto timeout: nota de destaque — "✓ Nenhum token foi debitado da sua carteira." Para timeout: nota cautelosa — "Verifique no explorador antes de tentar novamente."

Estado D: Confirmação parcial (aprovações concluídas, LP falhou)

Tratado como sub-caso do Estado C, com diferença no aviso: "Suas autorizações foram confirmadas — não será necessário repetir esse passo ao tentar novamente." Recovery idêntico ao Estado C pelo tipo de erro da TX de LP.

3. Regras de Negócio

Transição de estados: T06 começa no Estado A (pendente) assim que a TX de LP é submetida à rede. A tela escuta eventos da rede para a TX hash específica:

pending → Estado A
confirmed (receipt com status 1) → Estado B
confirmed (receipt com status 0 / reverted) → Estado C, com diagnóstico do erro
Cancelamento pelo usuário antes de submissão on-chain → Estado C (tipo: cancelado)
Timeout de 5 minutos sem confirmação → Estado C (tipo: timeout)

Retry com parâmetros preservados: Todo CTA "Tentar novamente" retorna para T04 com os parâmetros exatos da última tentativa: par, modo, valores, faixa (se Concentrada), slippage (possivelmente ajustado). Nunca retorna para T01 — o usuário não perdeu o trabalho de configuração.

Slippage sugerido no retry: Para erros de slippage excedido: calcular o slippage real da TX que falhou e sugerir o teto mínimo que teria passado + margem de 0,5%. Exibir como pré-ajuste ao retornar para T04, com nota "Ajustamos o slippage para X,X% com base na volatilidade recente deste pool." O usuário pode mudar antes de confirmar novamente.

Status in-range na posição criada (Concentrada): Badge de in-range/fora da faixa na posição criada é calculado com o preço atual no momento de exibição do Estado B — pode ser diferente do preço no momento do aporte se houve movimento durante o processamento. Se fora da faixa: banner âmbar: "O preço saiu da faixa configurada enquanto a transação era processada. Você não ganhará taxas até o preço retornar — considere ajustar a faixa." CTA "Ver posição" continua como primário.

Gas total pago: No Estado B, exibe o gas real total do fluxo: gas de aprovações + gas de LP. Não o gas estimado — o real. Para o usuário que comparou estimativa vs real ao longo do fluxo, esta linha encerra o ciclo.

"Ver no explorador" sempre disponível: Link de explorer presente em todos os estados de T06 — pendente, sucesso e erro. Em estados de pendência ou timeout: é o canal primário de verificação. Em estado de sucesso: é complemento para o intermediário que audita a TX.

4. Estados Não-Triviais

Pendente (nominal): Animação de loading. TX hash + link de explorer. Mensagem de contexto pedagógico colapsada. Link "Você pode fechar esta tela" disponível.

Pendente por mais de 2 minutos: Banner âmbar aparece: "A confirmação está demorando mais que o usual. Pode ser congestionamento na rede ou gas muito baixo." Link de explorer destacado. Sem timeout automático ainda.

Pendente por mais de 5 minutos (timeout): Transição para Estado C — tipo timeout. Aviso de cautela antes de retry.

Sucesso com posição in-range (nominal): Estado B descrito acima. Badge verde "● In-range".

Sucesso com posição fora da faixa (Concentrada): Estado B + banner âmbar adicional: "O preço saiu da faixa configurada — você não ganhará taxas até o preço retornar." CTA primário "Ver posição →" mantido; link "Ajustar faixa →" como ação secundária imediata.

Sucesso com pool inativa (APR ≈ 0): Estado B + nota discreta abaixo do resumo: "Este pool tem baixa atividade — o rendimento de taxas pode ser próximo de zero enquanto o volume não aumentar." Sem banner — o usuário foi avisado múltiplas vezes nas telas anteriores; aqui é apenas lembrete.

Erro — slippage excedido: Estado C com diagnóstico de slippage + CTA de retry com slippage pré-ajustado. Nota de não-perda de fundos.

Erro — gas insuficiente: Estado C com gas estimado vs real + CTA de compra de gas.

Erro — TX revertida (outro motivo): Estado C com link de explorer para diagnóstico técnico + CTA de retry.

Erro — usuário cancelou: Estado C com CTA "Retomar aporte" proeminente — usuário tem caminho claro de volta.

Confirmação parcial (aprovações OK, LP falhou): Estado C com nota "Autorizações mantidas — não precisará repeti-las ao tentar novamente."

Fechamento da tela antes da confirmação: Se o usuário fechar T06 enquanto a TX está pendente, a posição aparecerá em "Minhas posições" assim que confirmada. Na próxima vez que abrir o app: toast "Sua posição [Token A]/[Token B] foi criada." com link "Ver posição →".

5. Microcopy Crítico

Título da tela (estado pendente):

"Confirmando aporte..."

Título da tela (estado sucesso):

"Posição criada"

Título da tela (estado erro):

"Transação não executada"

Headline pendente:

"Registrando sua posição..."

Sub-headline pendente:

"Sua transação foi enviada — aguardando confirmação na rede [Nome da Rede]."

Accordion pedagógico:

"Por que demora? ▾" "Transações em blockchain são processadas em blocos. Na BNB Chain, cada bloco leva ~3 segundos; no Ethereum, ~12 segundos. Em períodos de alta demanda na rede, pode levar mais. Você não precisa manter a tela aberta."

Link "fechar tela" durante pendência:

"Você pode fechar esta tela — sua transação continuará sendo processada." "Sua posição aparecerá em 'Minhas posições' assim que confirmada."

Card TX:

"Transação: 0xAB12...CD34 ⬡ [Ver no explorador →]"

Headline sucesso:

"Posição criada com sucesso"

Card resumo — labels:

"Par e modo: [USDC/ETH] · Concentrada em um intervalo" "Aportado: X,XXXX USDC + X,XXXX ETH (≈ R$ X.XXX,XX)" "Faixa: R$ XX,XX – R$ YY,YY" "APR estimado: ~X,X% ao ano (estimativa 30d, sem Impermanent Loss) ⓘ" "Status: ● In-range" "Gas total pago: R$ XX,XX"

Badge in-range:

"● In-range — você está ganhando taxas"

Badge fora da faixa:

"● Fora da faixa — o preço saiu do intervalo configurado"

Banner fora da faixa:

"O preço saiu da faixa configurada enquanto a transação era processada. Você não ganhará taxas até o preço retornar — considere ajustar a faixa."

CTAs sucesso:

"Ver minha posição →" (primário) "Adicionar mais liquidez" (secundário) "Voltar ao início" (link terciário)

Link de explorer — sucesso:

"Ver transação confirmada →"

Headline erro — slippage:

"Transação não executada — slippage excedido"

Sub-headline erro — slippage:

"O preço mudou mais do que sua tolerância de slippage (X,X%) enquanto a transação estava sendo processada. Seus tokens não foram movidos."

CTA retry slippage:

"Tentar novamente com slippage maior (Y,Y%)"

Headline erro — gas:

"Transação não executada — gas insuficiente"

Sub-headline erro — gas:

"A transação precisou de mais gas do que o estimado. Seus tokens não foram movidos."

CTA retry gas:

"Comprar [ETH / BNB] para gas →"

Headline erro — cancelado:

"Transação cancelada"

Sub-headline erro — cancelado:

"Você cancelou a transação na carteira. Seus tokens não foram movidos."

CTA retry cancelado:

"Retomar aporte"

Headline erro — timeout:

"Transação sem confirmação"

Sub-headline erro — timeout:

"A transação está demorando mais que o esperado. Verifique no explorador antes de tentar novamente para evitar aporte duplo."

Nota de não-perda de fundos:

"✓ Nenhum token foi debitado da sua carteira."

Nota de autorizações mantidas:

"Suas autorizações foram confirmadas — não será necessário repeti-las ao tentar novamente."

Toast de posição criada (retorno ao app):

"✓ Sua posição [Token A]/[Token B] foi criada. [Ver posição →]"

6. Rastreabilidade Obrigatória

🟢 Herdado

Feedback visual explícito de estado — CTA/headline/componente muda por estado, não apenas cor: [uniswap-nova-posicao.md § Insight 3 — Feedback visual explícito de estado]; o produto deve comunicar o estado sem o usuário ter que inferir; os três headlines distintos (pendente / sucesso / erro) aplicam este princípio
Cobertura proativa de estados não-triviais — todos os resultados possíveis de TX endereçados: [pancake-final § Cobertura proativa de estados não-triviais]; estado não enumerado em produção vira bug de suporte; os 5 tipos de erro (slippage / gas / revertida / cancelada / timeout) cobrem os casos reais de falha de TX on-chain
Link de explorer disponível em todos os estados: [uniswap-visualizar-pool.md § Insight — Dados on-chain inline sem desvio para explorer externo]; o princípio simétrico se aplica ao resultado: quando a TX já está no explorador, o link pertence à tela de resultado
APR com caveat obrigatório no resumo de sucesso: padrão obrigatório cross-fluxo do design system Kotai — nunca exibir APR sem disclaimer de IL
CTA primário de sucesso nominado pela ação do usuário ("Ver minha posição"), não pela confirmação do sistema ("Concluído"): [pancake-final § Transparência proativa antes do CTA]; o CTA pós-sucesso não é decorativo — direciona a próxima intenção do usuário

🔴 Corrige

Diagnóstico específico por tipo de erro (não mensagem técnica de blockchain): corrige [pancake-final § Fricção 1 — Léxico de protocolo como vocabulário primário]; mensagens como "execution reverted: STF" são jargão de Solidity, não comunicação para usuário; cada tipo de erro recebe headline em linguagem natural + causa + confirmação de não-perda de fundos
Retry com parâmetros preservados (não retorno para T01): corrige convenção de indústria implicitamente apontada em [uniswap-nova-posicao.md § Fricção 1 — Versão como caixa-preta sem pedagogia]; obrigar o usuário a reconfigurar tudo após um erro de slippage é solução pior que o problema (A3) — o erro foi da rede, não da configuração do usuário
Nota de não-perda de fundos em estados de erro: corrige [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência] + [pancake-final § Pilar 4 — Educação contextual]; em produto financeiro, confirmação de "seus tokens estão seguros" após falha é obrigação de confiança, não polish — todos os concorrentes analisados omitem esta confirmação explícita
Gas real exibido no Estado B (não apenas estimado): deriva de [pancake-final § Insight — Transparência proativa antes do CTA] (fee total e breakdown explicitados antes e após o commit) e de [pancake-final § Pilar 4 — Educação contextual sistêmica + transparência financeira ativa]; a diferença entre gas estimado e gas real é informação financeira relevante, especialmente para redes congestionadas onde o gas real pode ser significativamente maior

🟡 Captura

Slippage sugerido no retry baseado no erro real (não ajuste manual pelo usuário): [uniswap-nova-posicao.md § Oportunidade 3 — Slippage adaptativo ao par/pool] estendido ao recovery de erro. Nenhum DEX analisado calcula e sugere o slippage mínimo necessário baseado no erro real da TX. Hipótese: usuário que recebe "Tente novamente com X,X%" tem taxa de sucesso no retry maior do que usuário que ajusta slippage manualmente (que tende a errar para cima por excesso de segurança ou para baixo por subestimar a volatilidade).
Badge in-range / fora da faixa imediatamente após criação da posição: derivado de [uniswap-visualizar-pool.md § Insight — Sinalização de risco/variação in-place]. Posição concentrada pode ficar fora da faixa durante o processamento se o mercado se mover. Mostrar o status real da posição no momento da confirmação — e a ação sugerida se estiver fora da faixa — diferencia o produto de DEXs que exibem o sucesso sem o estado real da posição criada. Hipótese: usuário que vê "● Fora da faixa — você não está ganhando taxas" imediatamente após o sucesso toma ação de ajuste de faixa com menor delay, reduzindo capital ocioso.
Accordion pedagógico de "Por que demora?" colapsado por default: derivado de [pancake-final § Pilar 4 — Educação contextual no ponto de decisão]. A ansiedade durante pendência de TX é causa de retries prematuros (usuário que submete de novo achando que "travou"). O accordion disponível — sem forçar leitura — responde à pergunta sem aumentar cognitive load para quem não precisa da explicação. Hipótese: taxa de retries prematuros (antes do timeout) cai com o accordion disponível.

⚪ Novo

Toast de posição criada ao retornar ao app após fechar a tela durante pendência: sem precedente nos consolidados. Justificativa: o usuário que fecha o app antes da confirmação precisa de um ponto de reencontro com o resultado da sua ação — sem ele, entra num estado de incerteza ("minha posição foi criada?") que leva a chamadas de suporte ou TX duplicada. O toast no retorno é o menor custo de implementação para o maior ganho de confiança. Custo: escuta de confirmação de TX em background (service worker ou push notification via app); armazenamento local do hash de TX pendente. Evidência a coletar: taxa de "minha posição não apareceu" em suporte antes/depois do toast.
Nota "Autorizações mantidas" em Estado de confirmação parcial (aprovações OK + LP falhou): sem precedente nos consolidados. Justificativa: em DeFi atual, o usuário que falha no aporte após ter aprovado os tokens não sabe se precisa aprovar de novo no retry — a incerteza leva ao abandono ou a chamadas de suporte. A nota elimina essa incerteza com 1 linha. Custo: detecção de "estado parcial" (aprovações confirmadas + TX de LP falhou) — trivial via estado do fluxo. Evidência a coletar: taxa de abandono no estado de erro de LP após aprovações bem-sucedidas.
Aviso de "aporte duplo" específico para estado de timeout: sem precedente nos consolidados. Justificativa: timeout é o único estado em que uma TX pode ainda confirmar enquanto o usuário está vendo a tela de erro — um retry imediato pode resultar em dois aportes do mesmo capital. O aviso "verifique no explorador antes de tentar novamente" é proteção financeira real. Custo: lógica de timeout (5 minutos sem receipt) já necessária para o Estado D. Evidência a coletar: frequência de TXs duplicadas em relatórios de suporte.

7. Trade-offs e Segunda Ordem

Complexidade da máquina de estados: T06 é a tela de maior complexidade de estados do fluxo — 5 variações (pendente, pendente-timeout, sucesso, sucesso-fora-de-faixa, erro × 5 tipos). Cada estado tem headline, sub-headline, card e CTA distintos. Risco: inconsistência de implementação entre estados, especialmente nos estados de erro raramente testados. Mitigação: especificação de microcopy por tipo de erro como parte desta proposta (não deixar para copywriting posterior); testes de integração cobrindo os 5 tipos de erro em staging.

Slippage sugerido no retry: Calcular o slippage mínimo necessário baseado no erro real da TX exige acesso ao preço real no momento da execução e à profundidade do pool no momento do erro — dados que podem não estar disponíveis se o indexador estiver lento. Fallback: sugestão de slippage atual + 1% se não houver dados do erro real. Aceitar o fallback — é melhor que não sugerir nada.

Badge in-range / fora da faixa: Exige preço atual no momento de exibição do Estado B — que pode ser diferente do preço no momento do aporte (TX processou enquanto o preço se movia). Risco de "falso positivo fora da faixa" se o preço saiu brevemente e voltou. Mitigação: calcular in-range com o preço spot atual, não com o preço histórico do bloco da TX — o que importa para o usuário é o estado atual, não o histórico.

Toast no retorno ao app: Exige persistência local do hash de TX pendente + listener de confirmação em background. Em mobile, service workers são menos confiáveis; in-app notification pode não disparar se o usuário não der permissão. Fallback: ao abrir o app, verificar TXs pendentes na sessão anterior e exibir o resultado na próxima tela que o usuário visitar (não necessariamente como toast — pode ser inline na tela de Minhas Posições).

Múltiplas superfícies de sucesso: o mesmo sucesso de posição pode ser visto em T06, em "Minhas posições" e em notificações. Evitar discrepância de dados entre essas superfícies — todas devem exibir o mesmo estado da posição no mesmo instante. Requer design de estado compartilhado (não re-fetch por surface).

i18n: Headline e sub-headline por tipo de erro = 10+ strings adicionais por idioma. Strings dinâmicas (token name, gas em R$, slippage percentual) exigem interpolação em todos os idiomas. Custo de manutenção real — cada novo tipo de erro adiciona strings. Mitigação: componente de "card de erro" com props de conteúdo (headline, sub-headline, CTA, nota) — não hardcoded por tipo de erro na camada de view.

Portfolio-03 — Receber criptos: fluxo guiado (2 passos)

1. Função da tela

Eliminar o principal vetor de perda não-maliciosa em DeFi para iniciantes — envio de token na rede errada — guiando o usuário pela escolha de token + rede antes de exibir o endereço, em vez de entregar endereço cru e transferir o risco de "rede certa" para o usuário ou para quem vai enviar.

Perfil-foco: iniciante (primary). Intermediário que usa múltiplas redes também se beneficia, mas o fluxo padrão é projetado para quem pode não saber o que é "rede" ou "endereço EVM".

2. Componentes / elementos

O fluxo é um bottom sheet de 2 passos que se expande sobre Portfolio-01 ou Portfolio-02 (contexto preservado ao fundo — Pilar 5, progressão sem perda de contexto).

Estruturais — Passo 1: Escolha o que você quer receber

Header do sheet

Label: "Receber criptos · Passo 1 de 2"
Ação de ajuda contextual: "📧 Pedir ajuda" no header (não no footer global) — posicionada onde o risco real está

Campo de busca de token

Placeholder: "Buscar token… (ex: USDC, ETH)"
Resultados em tempo real (debounce 300ms)

Lista de tokens — 2 seções:

Seção	Conteúdo
"Seus tokens"	Tokens que o usuário já tem na wallet, com saldo inline — mostra que o mesmo endereço serve
"Populares"	Tokens com maior volume de entrada na rede conectada (USDC, ETH, BNB…)

Cada item de token: ícone + nome do token + badge "X redes disponíveis"
Sem contrato hexadecimal como label primário — Pilar 1

Seleção de token → expansão de redes disponíveis

Ao selecionar um token, a linha expande inline (accordion) mostrando as redes onde aquele token tem liquidez e o produto suporta
Cada rede disponível: ícone + nome da rede + gas estimado de entrada (ex: "Ethereum · gas entrada ~R$12")
Badge "Recomendada" na rede com maior volume de transações de entrada para aquele token nos últimos 30d
Se o token tem apenas 1 rede suportada: expansão automática sem accordion (não há escolha a fazer)

CTA do Passo 1

"Continuar" — ativado somente após token + rede selecionados
Disabled com label dinâmico enquanto incompleto: "Escolha um token" → "Escolha a rede" → "Continuar"

Link para modo avançado

"Mostrar só o endereço (modo avançado) ↗" — texto de link discreto abaixo do CTA
Abre modal Tier 2 de confirmação antes de pular para Passo 2 sem guia

Estruturais — Passo 2: Seu endereço em [Rede selecionada]

Header do sheet

Label: "Seu endereço em [Nome da Rede]"
Ação de ajuda contextual: "📧 Pedir ajuda" (mantido do Passo 1)
Link "← Passo 1" para voltar e trocar token ou rede

Badge de identidade da operação (sticky no topo do conteúdo)

Ícone do token + separador "em" + ícone da rede + nome
Ex: "[ETH ⟶ Ethereum]" ou "[USDC ⟶ Polygon]"
Nunca desaparece — mesmo em scroll

QR Code

Grande, centralizado, de alta resolução
Codifica apenas o endereço (padrão); com "Compartilhar pedido", codifica endereço + token + rede

Endereço formatado

Exibido em fonte monoespaçada, quebrando por segmentos (legibilidade)
Botão "Copiar" ao lado — ação com feedback visual imediato (ícone muda para ✓ por 2s)

Aviso de rede (sempre visível, nunca tooltip hover-only)

Texto permanentemente visível, não tooltip, não bannerinho dismissível
Ex: "Envie apenas USDC em Polygon. Fundos enviados em outras redes podem ser perdidos permanentemente."
Cor: âmbar (atenção, não erro — o usuário ainda não fez nada errado)
Em mobile: posicionado imediatamente abaixo do QR code, antes do botão "Copiar"

Badge de rede (sempre visível)

"Endereço válido em [Polygon] · Não use em outras redes"
Ícone da rede inline

CTAs do Passo 2

Primário: "Compartilhar pedido de [TOKEN] em [REDE]" → cria deep link estruturado
Secundário (link): "Receber outro token" → volta ao Passo 1 com campos limpos

Toggle de modo avançado (somente após opt-in no Passo 1)

"Copiar só o endereço (sem contexto de rede)" — checkbox Tier 2 (não toggle simples; requer clique explícito)
Sub-label de consequência: "Quem receber o endereço precisará saber a rede corretamente"
Estado: OFF por default; marcação exige clique consciente (não acidental)

Cosméticos (segundo release)

Miniatura de prévia do QR code no Passo 1 (após seleção de token + rede, antes do CTA "Continuar")
Histórico de "Recebi recentemente de" com pares token+rede usados antes
Integração com EIP-681 para pedido de pagamento processável por outras wallets compatíveis

3. Regras de negócio

Filtro de redes por token:

Redes exibidas no Passo 1 = redes onde: (1) o token tem emissão verificada E (2) o produto suporta a rede
Se mapeamento token → redes não estiver disponível: fallback gracioso — mostrar todas as redes suportadas com aviso "Verifique se [TOKEN] está disponível na rede escolhida antes de enviar"
Redes sem liquidez do token (ex: token somente em Ethereum, sem ponte para Polygon) não são listadas — evita seleção de rede onde o recebimento seria impossível ou exigiria bridge

Badge "Recomendada":

Critério: rede com maior volume de transações de entrada para aquele token nos últimos 30d, conforme dados do indexador
Nunca determinístico por protocolo — não privilegia rede do produto sobre outras (anti-cross-promo, Fricção 5 do Uniswap-final)
Se dados indisponíveis: badge "Recomendada" não exibido (não adivinhar)

Aviso de rede — regra de exibição:

Sempre visível no Passo 2, independentemente do token ou rede selecionados
Nunca dismissível
Nunca tooltipado (hover-only viola Pilar 5 para mobile)

"Compartilhar pedido" — estrutura do deep link:

MVP (lançamento): texto formatado compartilhável via SO de compartilhamento nativo
- Exemplo: "Me envie [USDC] em [Polygon] para o endereço: 0xABCD…1234"
- Inclui rede explícita — elimina risco de rede errada na outra ponta mesmo sem protocolo
Versão futura: deep link com payload EIP-681 processável por wallets compatíveis

Modo avançado (skip de seleção token+rede):

Classificação Tier 2 (risco moderado mas consciência necessária) — NÃO Tier 1 (reversível com esforço; perda de fundos por rede errada é alta mas não certa)
Fluxo: clique em "Mostrar só o endereço" → modal com consequência explicada → "Cancelar" (primário) / "Continuar sem guia" (secundário, laranja) → Passo 2 com badge âmbar de aviso
No Passo 2 em modo avançado: aviso âmbar obrigatório, badge de rede não exibido (não há rede selecionada), QR code exibido sem contexto de token/rede
"Copiar só o endereço" checkbox em modo avançado: OFF por default; copiar sempre exige consciência de rede

Rede pré-selecionada (entrada via CTA contextual):

Se usuário chegar ao Portfolio-03 via "Receber ativos em [Rede]" (empty state de rede selecionada em Portfolio-02): rede pré-selecionada no Passo 1, mas token ainda requer seleção explícita
Pré-seleção de rede é aceleração, não bypass do fluxo guiado

Variante NFT:

Ativada quando Portfolio-03 é aberto via "Receber NFTs"
Passo 1: busca de coleção (não token); seção "Suas coleções" no topo
Header Passo 2: "Seu endereço para NFTs em [Rede]"
Aviso: "Envie apenas NFTs ERC-721 ou ERC-1155 em [Ethereum/Polygon]. Confirme que o endereço de destino é compatível com o padrão da coleção."
Endereço EVM é o mesmo (ERC-721/1155 usa mesmo endereço que tokens ERC-20 em redes EVM)

4. Estados não-triviais

Passo 1 — vazio (sem busca)

Lista: "Seus tokens" (wallet com saldo) + "Populares" (sem wallet ou sem tokens)
Se wallet sem tokens: seção "Seus tokens" omitida; apenas "Populares"

Passo 1 — busca sem resultados

Copy: "Nenhum token encontrado para '[X]'. Verifique o nome ou símbolo correto."
NÃO sugerir tokens similares (risco de scam por similaridade de nome — Fricção 3 do Uniswap-final)

Passo 1 — token selecionado, carregando redes disponíveis

Skeleton de 3 linhas no accordion de redes
CTA "Continuar" permanece disabled

Passo 1 — token selecionado, 0 redes disponíveis

Copy inline: "[TOKEN] não está disponível em nenhuma rede suportada atualmente."
Link: "Ver tokens disponíveis" → reseta busca e foca em "Populares"

Passo 2 — endereço carregado (estado principal do Passo 2)

QR, endereço, aviso e badge visíveis; CTAs ativos

Passo 2 — erro de geração de endereço

Copy: "Não foi possível gerar seu endereço. [Tentar novamente]"
NÃO exibir endereço parcial ou inválido

Passo 2 — modo avançado ativo

Badge âmbar permanente: "⚠ Modo direto ativo — informe a rede corretamente para quem vai enviar"
QR sem badge de rede (não há rede selecionada)
Aviso âmbar de rede substituído por aviso genérico: "Certifique-se de informar a rede correta para quem vai enviar. Fundos enviados na rede errada podem ser perdidos permanentemente."

Passo 2 — "Compartilhar pedido" (após toque)

SO de compartilhamento nativo abre com texto pré-formatado
NÃO redireciona para fora do app sem aviso

Variante NFT — aviso de padrão:

"Seu endereço EVM recebe NFTs ERC-721 e ERC-1155. Para outros padrões, verifique compatibilidade antes de enviar."

5. Microcopy crítico

Header Passo 1:

"Receber criptos · Passo 1 de 2"

Instrução Passo 1:

"Escolha o token e a rede antes de compartilhar seu endereço."

Placeholder de busca:

"Buscar token… (ex: USDC, ETH)"

Badge de rede no accordion:

Recomendada: "Recomendada · [N]% das transações de entrada nos últimos 30 dias"
Outras: "[Nome da Rede] · gas de entrada ~R$[X]"
Fallback sem dado de recomendação: sem badge (não adivinhar)

CTA Passo 1 (dinâmico):

Sem seleção: "Escolha um token"
Token selecionado, rede não: "Escolha a rede"
Completo: "Continuar"

Link modo avançado:

"Mostrar só o endereço (modo avançado) ↗"

Modal modo avançado (Tier 2):

"Você está saindo do fluxo guiado." "Sem o guia, você precisará informar a rede corretamente para quem vai enviar. Fundos enviados na rede errada podem ser perdidos permanentemente." — [Cancelar] (primário, azul) · [Continuar sem guia] (secundário, laranja)

Header Passo 2:

"Seu endereço em [Nome da Rede]"

Link de retorno:

"← Passo 1"

Badge de identidade (sticky):

"[ícone TOKEN] em [ícone REDE] [Nome da Rede]"

Aviso de rede (sempre visível, nunca tooltip):

"Envie apenas [TOKEN] em [REDE]. Fundos enviados em outras redes podem ser perdidos permanentemente."

Badge de rede:

"Endereço válido em [REDE] · Não use em outras redes"

CTA primário Passo 2:

"Compartilhar pedido de [TOKEN] em [REDE]"

CTA secundário (link):

"Receber outro token"

Checkbox modo avançado:

"Copiar só o endereço (sem contexto de rede)" Sub-label: "Quem receber precisará saber a rede corretamente"

Badge de modo avançado (âmbar, sempre visível):

"⚠ Modo direto ativo — informe a rede corretamente para quem vai enviar"

Ajuda contextual (header, Passo 1 e 2):

"📧 Pedir ajuda"

Erro de busca sem resultado:

"Nenhum token encontrado para '[X]'. Verifique o nome ou símbolo correto."

Erro de geração de endereço:

"Não foi possível gerar seu endereço. [Tentar novamente]"

Texto de "Compartilhar pedido" (MVP, via compartilhamento nativo):

"Me envie [USDC] em [Polygon] para o endereço: 0xABCD…1234" (inclui rede explicitamente — elimina risco de rede errada na outra ponta)

Variante NFT — aviso de padrão:

"Seu endereço EVM recebe NFTs ERC-721 e ERC-1155 nesta rede. Confirme com quem vai enviar que a coleção usa esses padrões."

6. Rastreabilidade obrigatória

🟢 Herdado

Ajuda contextual no header de modal de ação sensível — "📧 Pedir ajuda" posicionado onde o risco está (Passo 1 e 2), não no footer global. Replicação consciente da decisão Uniswap. [uniswap-portfolio § Insight — Suporte contextual dentro de modais de ação sensível, telas 4 e 6]
Copy que declara o porquê / o que pode acontecer — "Fundos enviados em outras redes podem ser perdidos permanentemente" é declaração literal de consequência, não ícone de aviso genérico. [uniswap-final § Insight — Copy preventiva que declara o porquê / o que NÃO acontece]
Microcopy na linguagem mental do usuário — "Receber criptos" (não "Receive"); nome da rede (não "EVM", não "chain-id"); "token" (não "contract"). Pilar 1. [uniswap-portfolio § Insight — Microcopy na linguagem mental do usuário] [pancake-final § Pilar 1 — Naming system]
Aviso sempre visível, nunca tooltip hover-only — crítico para mobile; tooltip hover viola Pilar 5. [pancake-final § Pilar 5 — Mobile-first interaction]
CTAs com label do próximo obstáculo específico — "Escolha um token" → "Escolha a rede" → "Continuar" em vez de CTA disabled silencioso. [pancake-final § Insight — CTAs descrevem o bloqueio com causa específica] [pancake-final § Fricção 10 — CTA disabled silencioso sem comunicar o gap]
Defesa em camadas para modo avançado — modal Tier 2 com consequência explicada, "Cancelar" como primário, ação de risco como secundário laranja. NÃO CTA verde primário para ação de risco. [pancake-final § Pilar 2 — Defesa em camadas universal] [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência]
"Don't show this again" proibido — modal Tier 2 do modo avançado não tem checkbox "Não mostrar novamente". [pancake-final § Pilar 7 — Curadoria opinionada + Modo avançado opt-in]

🔴 Corrige

Vetor de perda por token-rede mismatch no modal Receber — Uniswap entrega endereço cru sem guia de token+rede; Kotai força escolha de token + rede antes de exibir endereço. Elimina o principal vetor de perda não-maliciosa de DeFi para iniciante. [uniswap-portfolio § Fricção — Vetor de perda por token-rede mismatch, tela 4]
Endereço sem identificador de rede em momento de compartilhamento — PancakeSwap e Uniswap entregam endereço sem badge de rede. Kotai: badge de rede sempre visível + aviso textual sempre visível + "Compartilhar pedido" inclui rede explícita. [pancake-carteira-conectada § Fricção — Endereço sem identificador de rede, telas 5, 6, 8] [pancake-final § Fricção 4 — Endereço/agregação sem identificador de rede]
Affordances niveladas para ações de risco diferente — modo avançado (skip do guia) classificado como Tier 2, com modal de confirmação, não toggle direto igual a preferência cosmética. [pancake-final § Fricção 3 — Listas e controles sem hierarquia de consequência]
Gap entre instrução do empty state e CTA correspondente — em Portfolio-01 e 02, o CTA "Receber tokens" e "Receber NFTs" abre diretamente este fluxo, fechando o gap que Uniswap deixa aberto. [uniswap-portfolio § Fricção 3 — Gap entre instrução do empty state e CTA correspondente]

🟡 Captura

Receber como fluxo guiado token-rede-first, não endereço-first — toda a estrutura do Passo 1 implementa esta oportunidade. Pilar 5 + Pilar 3. Hipótese de diferenciação: taxa de perda de fundos por rede errada → 0% para usuários que seguem o fluxo padrão (métrica mensurável pós-lançamento via tx análise de falha). [uniswap-portfolio § Oportunidade — Receber como fluxo guiado token-rede-first]
Receive como pedido de pagamento estruturado — "Compartilhar pedido" com rede explícita no texto elimina risco de rede errada na outra ponta. MVP (texto formatado) valida o conceito; versão EIP-681 no roadmap. Hipótese: taxa de uso de "Compartilhar" vs "Copiar endereço" indica adoção do padrão. [pancake-carteira-conectada § Oportunidade — Receive como pedido de pagamento estruturado]
Error states com diagnóstico + ação — "Não foi possível gerar seu endereço. [Tentar novamente]" vs. genérico "Algo deu errado". Cada falha tem causa + ação. [uniswap-portfolio § Oportunidade — Error states com diagnóstico + ação]

⚪ Novo

Filtro de redes por token (redes onde o token tem emissão verificada): nenhuma DEX analisada filtra redes por token específico na tela de recebimento — todas listam todas as redes suportadas independentemente. Justificativa: evita que usuário selecione rede onde o token não existe (ex: USDC nativo em Solana, endereço EVM entregue → incompatibilidade). Custo: mapa token → redes com emissão verificada, atualizado periodicamente. Fallback gracioso se mapa indisponível: mostrar todas as redes suportadas + aviso "Verifique se [TOKEN] está disponível nesta rede antes de enviar". Evidência a coletar: frequência de tentativas de selecionar rede onde token não existe (indicador de confusão de emissão cross-chain).
Accordion de expansão de rede inline (no Passo 1, ao selecionar token): mantém contexto de qual token está selecionado durante a escolha de rede, em vez de navegar para tela separada de seleção de rede. Sem precedente nos concorrentes (todos navegam para tela separada ou entregam endereço diretamente). Justificativa: accordion preserva contexto visual (token selecionado permanece visível) sem adicionar nível de navegação. Risco: accordions longos em mobile com muitas redes podem precisar de scroll. Mitigação: limitar a 8 redes por token no accordion; overflow vira "Ver mais redes (+X)". Evidência a coletar: taxa de abandono em mobile no momento de expansão de redes vs. desktop.
"Compartilhar pedido" como texto formatado com rede explícita (MVP): texto formatado "Me envie [TOKEN] em [REDE] para o endereço: 0x..." não tem precedente como padrão nos DEXs analisados. Pancake tem gift code (payload estruturado), mas é product-specific (token da casa). Justificativa: elimina o risco de rede errada na outra ponta sem exigir protocolo complexo; compartilhamento via WhatsApp, Telegram e SMS (canais primários BR) não suporta deep links de wallet — texto funciona em todos os canais. Evidência a coletar: canal de compartilhamento mais usado (WhatsApp vs. outros) + taxa de transações recebidas com sucesso após uso de "Compartilhar pedido" vs. "Copiar endereço".

7. Trade-offs e segunda ordem

2 passos em vez de 1 (adição de 1 clique no caminho feliz):

Custo: usuário que já sabe a rede tem 1 clique extra.
Justificativa: custo de 1 clique vs. custo de perda irreversível de fundos (pode ser centenas de dólares) — aceitar.
Modo avançado mitiga para power user sem abrir exceção no fluxo padrão.

Mapa token → redes com emissão verificada:

Custo: manutenção contínua — novos tokens em novas redes precisam de atualização.
Fallback gracioso (mostrar todas + aviso): garante que o produto nunca quebra por dado faltando.
Dado disponível via indexadores existentes (The Graph, GoldRush/Covalent) — não requer scraping proprietário.

Accordion de redes inline no Passo 1:

Mais estado de componente (accordion aberto/fechado + seleção de rede) → mais testes de QA.
Mobile: accordion com > 6 redes precisa de scroll interno ou "Ver mais"; testar em viewports de 375px.

Badge "Recomendada" baseado em dados de 30d:

Dados de volume de entrada podem ser manipulados (wash trading) — mitigar com critérios multi-sinal (volume + count de transações únicas + tempo de existência do par).
Se dados indisponíveis: badge não exibido (fallback honesto).

"Compartilhar pedido" via compartilhamento nativo:

Não é universal: compartilhamento nativo iOS/Android funciona bem; web app sem PWA não tem acesso à API nativa. Fallback: "Copiar texto do pedido" (clipboard) quando API de compartilhamento indisponível.
Texto formatado não é processável automaticamente por outra wallet — é informação para humano ler e agir. Versão EIP-681 resolve isso, mas exige adoção pela wallet destinatária.

Aviso âmbar de rede permanentemente visível:

Pode criar "warning fatigue" em usuários frequentes que já entendem o risco.
Mitigação: depois de N (≥ 10) usos bem-sucedidos, considerar reduzir visibilidade para nota discreta. Sem implementar no MVP — coletar dados antes de suavizar proteção.
"Don't show this again": proibido para este aviso (Tier 1 by consequence — perda de fundos é possível). Veja Pilar 7.

Adicionar Liquidez — Tela 07: Modal de Seleção de Pool — Comparação Assistida por Fee Tier e Saúde

1. Função da tela

Modal/bottom sheet que aparece quando o par selecionado em T01 tem dois ou mais pools disponíveis (fee tiers distintos, tipos de AMM distintos, ou ambos) — permitindo que o usuário compare e escolha o pool correto antes de configurar o aporte, com cada opção descrita por consequência financeira e não por terminologia de AMM. Foco: iniciante que não sabe o que "0,3%" significa em termos de retorno esperado, e intermediário que quer ver dados de saúde antes de comprometer capital.

2. Componentes / Elementos

Estruturais (definem o paradigma da tela)

a) Header fixo "Escolher pool para [Token A]/[Token B]" + ícone combinado do par (sobreposição dos dois avatares) + botão × no canto direito (fecha o modal e mantém o par selecionado em T01, com o pool recomendado como seleção padrão). Sub-label: "N pools disponíveis nesta rede."

b) Cards de pool comparativos — componente central Um card por pool disponível, empilhados verticalmente. Ordenados por TVL decrescente por default. Cada card contém, em hierarquia:

Fee tier em linguagem de consequência (label primário, não o percentual nu):
- "Taxa muito baixa (0,01%) · Ideal para pares estáveis"
- "Taxa baixa (0,05%) · Ótima para pares com pouca volatilidade"
- "Taxa padrão (0,3%) · Mais comum para pares com volatilidade moderada"
- "Taxa alta (1%) · Para tokens de menor liquidez — compensação maior por swap"
Secondary label técnico discreto: "V3 · 0,05% por swap" — nome de protocolo como subtexto, não label primário
Métricas de saúde do pool:
- "Liquidez total: R$ X,XX M"
- "Volume 24h: R$ X,XX M"
- "APR estimado: ~X,X% ao ano (estimativa 30d, sem IL) ⓘ"
Badge de atividade: ● Ativo (verde) / ⚠ Baixa atividade (âmbar) / ● Inativo (vermelho)
CTA de seleção: "Selecionar este pool" (mesmo estilo para todos os cards — a hierarquia é comunicada pelo badge de recomendação, não pelo estilo do botão)

c) Badge "Recomendado para este par ✓" Exibido no card do pool que o sistema recomendou em T01 (mesma heurística de T01 — não muda ao entrar no modal). O badge é explicativo, não apenas ornamental: tooltip "Recomendado com base na liquidez disponível e no perfil do par." Card recomendado fica no topo da lista, independente de sort.

d) Controles de ordenação (secondary, no canto superior direito do modal) Dois sort buttons: "Mais liquidez" (default) / "Maior rendimento". Sort afeta apenas a ordem dos cards não-recomendados — o recomendado permanece no topo. Botões de sort sem dropdown — dois estados simples.

e) Banner de aviso contextual (condicional — aparece em cenários específicos) Pool com APR > 200%: badge âmbar "Rendimento atípico ⓘ" inline no card. Tooltip: "APR muito acima da média pode indicar incentivo temporário ou baixa liquidez — o rendimento tende a cair à medida que mais capital é aportado." Não bloqueia seleção; sinaliza antes do clique.

Cosméticos

Indicador de "N de M selecionado" no header conforme o usuário foca em um card
Número discreto de posições ativas no pool ("X provedores de liquidez" como tooltip ao ⓘ ao lado do TVL — não linha visual proeminente)
Timestamp de atualização das métricas: "Dados atualizados há N min"

3. Regras de Negócio

Trigger: T07 é acionado de T01 quando:

O usuário clica em "Ver N pools disponíveis ▾" no card de saúde do pool
O usuário clica em "Ver outras opções" no badge "Recomendado para este par" Nunca aparece quando há apenas 1 pool para o par — o único pool é selecionado automaticamente em T01 e o health card exibe "Único pool disponível para este par nesta rede."

Seleção padrão ao abrir: O pool recomendado pelo sistema está visualmente destacado (card com borda de destaque + badge), mas não é "confirmado" — o usuário precisa clicar "Selecionar este pool" ou fechar o modal (×) para aceitar a recomendação como está.

Fechamento sem seleção: Se o usuário fecha o modal via × sem clicar em nenhum CTA: o pool recomendado permanece como seleção padrão em T01. Não há "nenhum pool selecionado" — a recomendação do sistema serve como fallback.

Seleção de pool não-recomendado: Ao selecionar um pool diferente do recomendado: o modal fecha, o health card de T01 atualiza com os dados do pool escolhido, e o badge no health card muda de "Recomendado ✓" para "Selecionado ✓ (Taxa de X,XX%)". O usuário pode abrir T07 novamente para trocar.

Ordenação: Sort "Mais liquidez": TVL decrescente. Sort "Maior rendimento": APR decrescente. Em ambos os casos, o pool recomendado permanece no topo — a ordenação aplica apenas aos demais pools.

Pool inativo (Vol/TVL < 0,001): Card exibido por último na lista (mesmo com sort por rendimento), com badge vermelho "Pool inativa". Não removido da lista — não bloquear seleção consciente. A posição no final da lista é o sinal de dissuasão, não o bloqueio.

Propagação de dados para T01/T02/T03: Ao selecionar um pool, o ID do pool selecionado propaga para T01 e, na sequência, para T02/T03. O formulário de configuração usa os parâmetros do pool selecionado (fee tier para cálculos, liquidez para slippage estimado).

4. Estados Não-Triviais

Loading (ao abrir o modal): Skeleton nos cards. Spinner no indicador de "N pools disponíveis". Se > 3s: "Buscando pools disponíveis... pode levar alguns segundos."

1 pool disponível (não abre modal): T07 não é renderizado. Em T01, o health card exibe "Único pool disponível para este par nesta rede" e o usuário avança diretamente para T02/T03.

Todos os pools inativos: Banner âmbar no topo do modal: "Todos os pools para [Token A]/[Token B] estão com baixa atividade — o rendimento de taxas pode ser próximo de zero. Você pode prosseguir ou escolher outro par." CTA de seleção de todos os cards muda para "Selecionar mesmo assim" (laranja). Não bloqueia — alerta com saída explícita.

Pool com APR atípico (> 200%): Badge âmbar "Rendimento atípico ⓘ" no card, inline. Tooltip com explicação. CTA "Selecionar este pool" mantido em estilo normal — o badge já comunica o risco.

Erro de dados (RPC lento): Modal exibe mensagem central: "Não foi possível carregar dados dos pools. [Tentar novamente]" com botão de retry. Se retry falhar: "Selecionar sem dados" disponível com nota "Os dados de liquidez e APR estão indisponíveis — você pode selecionar com base no fee tier apenas."

Sucesso — pool selecionado: Modal fecha com animação de colapso suave. Health card de T01 atualiza com os dados do pool escolhido. Badge "Selecionado ✓ (Taxa de X,XX%)" se pool diferente do recomendado. Badge "Recomendado para este par ✓" mantido se o usuário escolheu o recomendado.

5. Microcopy Crítico

Título do modal:

"Escolher pool para [USDC/ETH]"

Sub-label do título:

"3 pools disponíveis nesta rede · Escolha onde aportar sua liquidez"

Badge de recomendação:

"Recomendado para este par ✓"

Tooltip do badge:

"Recomendado com base na liquidez disponível e no perfil deste par."

Labels de fee tier — primário:

"Taxa muito baixa (0,01%) · Ideal para pares estáveis — slippage mínimo em grandes volumes" "Taxa baixa (0,05%) · Ótima para pares com pouca volatilidade — boa liquidez, custo menor por swap" "Taxa padrão (0,3%) · Mais comum para pares com volatilidade moderada — equilíbrio entre custo e rendimento" "Taxa alta (1%) · Para tokens de menor liquidez — compensação maior por swap, liquidez menor"

Secondary label técnico:

"V3 · 0,05% por swap"

Métricas:

"Liquidez total: R$ 2,34 M" "Volume 24h: R$ 450 mil" "APR estimado: ~4,2% ao ano (estimativa 30d, sem Impermanent Loss) ⓘ"

CTA por card:

"Selecionar este pool"

CTA pool inativo:

"Selecionar mesmo assim" (laranja)

Sort buttons:

"Mais liquidez" / "Maior rendimento"

Badge pool inativa:

"● Pool inativa · Vol/TVL < 0,1% · Rendimento pode ser próximo de zero"

Badge APR atípico:

"Rendimento atípico ⓘ"

Tooltip APR atípico:

"APR muito acima da média pode indicar incentivo temporário ou baixa liquidez. O rendimento tende a cair à medida que mais capital é aportado — verifique a sustentabilidade antes de aportar."

Banner todos os pools inativos:

"Todos os pools para [Token A]/[Token B] estão com baixa atividade — o rendimento de taxas pode ser próximo de zero. Você pode prosseguir ou escolher outro par."

Erro de dados:

"Não foi possível carregar dados dos pools. [Tentar novamente]"

Fallback sem dados:

"Selecionar sem dados de liquidez" "Os dados de APR e TVL estão indisponíveis agora — você pode escolher pelo fee tier."

Feedback pós-seleção no health card de T01:

"Selecionado ✓ (Taxa de 0,3%)"

Pool único (aparece em T01, não em T07):

"Único pool disponível para este par nesta rede"

6. Rastreabilidade Obrigatória

🟢 Herdado

Pool recomendado pré-selecionado como default contextual: [pancake-final § Defaults pró-iniciante sem pedir permissão] — sistema assume responsabilidade de curadoria sem forçar o usuário a escolher do zero; o usuário pode sobrepor, mas o default é o correto para o par.
Badge de saúde do pool com estados diferenciados (● Ativo / ⚠ / ● Inativo): padrão estabelecido em adicionar-liquidez-01 do design system Kotai — mesmo componente e semântica visual.
APR com caveat obrigatório "(estimativa 30d, sem IL) ⓘ": padrão obrigatório cross-fluxo do design system Kotai (suas-posicoes, criar-pool, adicionar-liquidez-01/02/03/04).
Progressive disclosure — T07 aparece on-demand, não como passo obrigatório: [uniswap-final § Progressive disclosure como padrão arquitetural, não recurso pontual] — o usuário que aceita a recomendação de T01 nunca precisa abrir T07; o modal existe para quem quer decidir conscientemente.
Secondary label técnico para fee tier (percentual + nome de protocolo): [uniswap-nova-posicao.md § Insight 2 — Microcopy pedagógica inline] + Pilar 1 Kotai (nome técnico como secondary label, nunca como label primário).
Risk signaling inline no card antes do clique (APR atípico, pool inativa): [uniswap-final § Fricção 3 — Listas/métricas sem risk signaling nem fenestração de curadoria] + [pancake-final § Pilar 6 — Risk signaling sistêmico] — sinalizar risco em listas de pools antes do clique é diretriz obrigatória do design system.

🔴 Corrige

Labels de fee tier por consequência financeira, não por terminologia de AMM: corrige [pancake-adicionar-liquidez.md § Fricção 2 — Componente de filtro de pool: vocabulário intraduzível e UX degradada] (CLAMM/LBAMM/Classic sem definição, telas 4/6/7 do Pancake) + [uniswap-nova-posicao.md § Fricção 1 — Versão como caixa-preta técnica] (fee tier como lista nua sem trade-off). A solução é labels em camadas: consequência financeira (primário) + termo técnico (secondary).
Microcopy de fee tier inteiramente em PT-BR: corrige [pancake-adicionar-liquidez.md § Fricção Sistêmica — Localização incompleta: inglês técnico dentro de UI PT-BR] — "CLAMM", "Dynamic Fees", "Classic" em inglês nos filtros de pool do Pancake são o caso mais crítico de i18n incompleto deste fluxo.
Pool inativa visível no final da lista (não removida silenciosamente): corrige [uniswap-final § Fricção 3 — Listas sem fenestração de curadoria] — esconder pools ruins protege o iniciante mas remove controle do avançado; a posição no final da lista é a solução de equilíbrio (curadoria visível, não bloqueio).
Fechamento de modal sem destruir seleção de par em T01: corrige [uniswap-nova-posicao.md § Ponto isolado, Tela 4 — Troca de versão pode redefinir formulário silenciosamente] — saída de sub-fluxo preserva estado da tela-pai.

🟡 Captura

Filtros de pool por consequência financeira, não por mecânica técnica: [pancake-adicionar-liquidez.md § Oportunidade 2 — Filtros de pool por consequência financeira: "Alta eficiência de capital" em vez de "CLAMM"]. Labels como "Taxa padrão (0,3%) · Mais comum para pares com volatilidade moderada" entregam a consequência sem exigir que o usuário conheça a arquitetura da AMM. Hipótese: iniciante que lê "Taxa baixa · Ideal para pares com pouca volatilidade" escolhe o pool correto com maior frequência do que iniciante que lê "0,05% fee tier".
Comparação simultânea de pools (não seleção sequencial): derivado de [pancake-final § Painel master/detail preservando contexto + progressive disclosure] — ver todas as opções no mesmo plano de decisão (não um de cada vez em dropdown) permite comparação real sem perda de contexto. Hipótese: usuário que compara APR + TVL lado a lado tem taxa de seleção de pool ativo maior do que usuário que seleciona de dropdown sequencial.
Badge de APR atípico com explicação de mecanismo (não apenas alerta): [uniswap-final § Fricção 6 — Métricas DeFi sem decomposição, janela ou comparativo] + [pancake-final § Pilar 6 — Risk signaling sistêmico]. A explicação "APR tende a cair à medida que mais capital é aportado" é educação financeira DeFi no ponto de decisão — diferencial sobre concorrentes que exibem "APR 523%" sem contexto.

⚪ Novo

Sort "Mais liquidez" / "Maior rendimento" — dois estados simples, sem dropdown: sem precedente nos consolidados como padrão de sort para pool picker. Justificativa: a maioria dos DEX não oferece sort explícito no seletor de fee tier (Uniswap mostra fee tier como lista estática; Pancake tem filtros por tipo mas não por saúde). Dois botões de sort simples reduzem cognitive load vs. dropdown enquanto entregam as duas dimensões de comparação mais relevantes para o par de iniciante/intermediário. Custo: lógica de ordenação condicional no componente de card. Evidência a coletar: frequência de uso do sort "Maior rendimento" vs "Mais liquidez" — se "Maior rendimento" dominar, isso indica que os usuários estão usando APR sem entender o risco, e o aviso de APR atípico precisa ser mais proeminente.
Pool recomendado permanece no topo independente do sort: sem precedente nos consolidados. Justificativa: se o sort move o pool recomendado para o meio ou fim da lista, o usuário perde a referência de "o que o sistema acha que é melhor". O custo de fixar o recomendado no topo é baixo (posição condicional na lista). Evidência a coletar: taxa de seleção do pool recomendado vs. taxa de override — se > 70% escolhe o recomendado, a heurística está bem calibrada.

7. Trade-offs e Segunda Ordem

Heurística de recomendação precisa ser confiável: O badge "Recomendado para este par" é um endorsement do produto. Se a heurística recomendar o pool errado (ex: fee tier 0,3% para USDC/USDT onde 0,05% tem profundidade muito maior), o badge amplifica o erro. Mitigação: a heurística é a mesma de T01 — calibrada por TVL e Vol/TVL, não por número de fee tier. Revisão trimestral com dados de perdas por pool mal selecionado.

Labels de fee tier por consequência exigem copywriting especializado: "Taxa padrão (0,3%) · Mais comum para pares com volatilidade moderada" pode estar desatualizado se as condições de mercado mudarem. Mitigação: os labels descritivos são propriedades do componente de card (não hardcoded na view) e revisados por release. O percentual sempre aparece como part do label — se a descrição ficar desatualizada, o dado primário (0,3%) permanece correto.

Overhead de UX para o usuário que só quer aceitar a recomendação: Abrir T07 para ver opções adiciona uma step ao fluxo. Mitigação: T07 só é ativado por ação explícita do usuário ("Ver N pools disponíveis ▾") — quem aceita o recomendado nunca vê o modal. O modal existe para quem quer controle, não para quem quer velocidade.

i18n: 4 labels de fee tier × 3 strings cada (label curto, label longo, secondary técnico) = 12 strings adicionais por idioma + strings de badge e sort = ~18 strings. Custo real de manutenção quando novos fee tiers forem adicionados (ex: fee tier de 0,5% em protocolo futuro). Mitigação: componente de card de pool com props de conteúdo (label, secondary, threshold de aviso) — não hardcoded por fee tier.

Mobile: cards empilhados com muitas métricas: Em viewport estreito (< 375px), cada card com 4 linhas de métrica pode exceder o viewport sem scroll. Mitigação: em mobile, métricas colapsadas por default em cada card (apenas fee tier label + badge de atividade + "Ver detalhes ▾") — a comparação expandida em desktop, o score qualitativo em mobile. Expandir um card colapsa os outros (accordion behavior).

Adicionar Liquidez — Tela 08: Aumentar Liquidez em Posição Existente

1. Função da tela

Formulário condensado para adicionar capital a uma posição LP já existente, sem re-seletar par, modo ou faixa de preço — apenas os novos valores a depositar. É um entry point alternativo ao fluxo de Adicionar Liquidez que parte de uma posição conhecida (ID #NNNN) e respeita os parâmetros fixos dela, com aviso proeminente quando a posição concentrada está fora da faixa no momento do aporte. Foco: intermediário que já opera LP e quer aumentar exposição de forma rápida; iniciante que volta à posição pelo CTA "Adicionar mais liquidez" de T06 e precisa do caminho mais direto.

2. Componentes / Elementos

Estruturais (definem o paradigma da tela)

a) Mini-card de identidade da posição (sticky no topo — substitui o health card de T01) Não é o health card genérico do pool — é o cartão específico da posição do usuário, com:

Par + modo em label de benefício (ex: "USDC/ETH · Concentrada em um intervalo")
Fee tier + ID da posição: "Taxa 0,3% · Posição #3847"
Para modo Concentrada: faixa de preço configurada: "Faixa: R$ XX,XX – R$ YY,YY" + badge de status:
- ● Dentro da faixa (verde): "● Dentro da faixa — você está ganhando taxas"
- ● Fora da faixa (âmbar): "● Fora da faixa — você não está ganhando taxas"
Para modo Simples: proporção atual do pool: "Proporção atual: 52% USDC / 48% ETH"
APR estimado com caveat obrigatório: "~X,X% ao ano (estimativa 30d, sem Impermanent Loss) ⓘ"
Badge de atividade do pool: ● Ativo / ⚠ Baixa atividade / ● Inativo

b) Indicador de contexto do fluxo (substitui o stepper de 3 passos de T01-T06) O stepper completo (Par e modo / Configurar / Confirmar) não aparece — este é um sub-fluxo sem re-seleção. No lugar: indicador compacto de contexto no topo do formulário:

"Adicionando ao par [USDC/ETH] · Posição #3847"

com botão de retorno lateral: "← Voltar à posição" (retorna para visualizar-posicao).

c) Banner de aviso — posição fora da faixa (estrutural — condicional para Concentrada out-of-range) Aparece imediatamente abaixo do mini-card quando o badge é "Fora da faixa". Banner âmbar com ícone ⚠, texto em duas partes:

Linha principal: "Sua posição está fora da faixa atual — adicionar liquidez aqui não renderá taxas até o preço retornar ao intervalo configurado."
Dois CTAs de saída explícita:
- "Ajustar a faixa →" (primário — redireciona para tela de gerenciamento de range, fora deste fluxo)
- "Adicionar mesmo assim" (laranja — fecha o banner e habilita o formulário)

O formulário de aporte não está acessível até o usuário escolher uma das duas ações do banner — a faixa fora do range é informação crítica que exige decisão consciente antes de prosseguir. Esta regra segue a hierarquia de defesa em camadas do Pilar 3: confirmação exigida para ação com risco financeiro não-trivial.

d) Campos de aporte (locked ao modo da posição existente) Para modo Concentrada:

Ambos os campos (Token A e Token B) editáveis
Proporção calculada pelo range atual da posição, não pelo pool geral
Ao inserir Token A: Token B calcula automaticamente com base na faixa configurada (mesma lógica de T02)
Sub-label em Token B: "(Calculado com base na faixa da sua posição)"
Preset chips: 25% / 50% / 75% / Tudo (baseados no saldo disponível)
Equivalente R$ abaixo de cada campo
Nota discreta abaixo dos campos: "Esta posição usa a faixa R$ XX,XX – R$ YY,YY — o aporte segue a mesma proporção."

Para modo Simples (V2) e Par Correlacionado (StableSwap):

Token A editável; Token B calculado automaticamente com base na proporção atual do pool
Sub-label em Token B: "(Calculado automaticamente com base no preço atual)"
Mesma lógica de T03

Para modo Simples (V2) com posição cujo token A ou B mudou de proporção desde o aporte original:

Sub-label de proporção: "Proporção atual do pool: X% [Token A] / Y% [Token B] (diferente do aporte original — o pool mudou de proporção)"
Não bloquear — apenas informar.

e) APR estimado com caveat obrigatório "~X,X% ao ano (estimativa 30d, sem Impermanent Loss) ⓘ" — idêntico ao padrão do design system Kotai. Tooltip com explicação de IL.

f) Card de custo agregado (após campos preenchidos)

Total a adicionar:    R$ X.XXX,XX
Gas estimado:         ~R$    XX,XX
────────────────────────────────────
Você paga agora:      R$ X.XXX,XX

Sub-label: "O total adicionado permanece seu na posição — o gas é o custo para registrar na rede." Nota adicional quando aprovações necessárias: "Gas da autorização: ~R$ XX,XX por token (cobrado antes desta etapa)."

g) CTA principal Label dinâmico conforme o estado. Disabled até ambos os valores preenchidos + saldo suficiente.

Cosméticos

Saldo disponível abaixo de cada campo
Timestamp "Preço atual: R$ X.XXX,XX · Atualizado há N min"
Separador visual entre o mini-card e o formulário de aporte
Link discreto "Ver detalhes completos da posição →" no mini-card (abre visualizar-posicao em nova aba)

3. Regras de Negócio

Parâmetros fixos da posição: Par, modo, fee tier, e faixa de preço (para Concentrada) são readonly e não editáveis nesta tela. O usuário que quiser mudar qualquer um desses parâmetros deve ir para a tela de gerenciamento da posição. Para criar uma posição nova com parâmetros diferentes, usar T01. O mini-card comunica isso visualmente (dados exibidos, sem campo de edição).

Posição out-of-range (Concentrada): O banner de aviso aparece imediatamente ao entrar em T08. O formulário de aporte é inacessível até o usuário fazer uma escolha explícita: "Ajustar a faixa →" ou "Adicionar mesmo assim" (laranja). Clicar em "Adicionar mesmo assim" fecha o banner e libera o formulário — com nota persistente e discreta no mini-card: "● Fora da faixa · Você optou por adicionar fora do intervalo." A nota persiste durante o preenchimento do formulário como lembrete, não como bloqueio.

Proporção para Concentrada: A proporção de Token A / Token B depende do preço atual em relação à faixa configurada:

Preço próximo ao limite inferior da faixa: maioria do aporte em Token A
Preço no meio da faixa: proporção ~50/50
Preço próximo ao limite superior: maioria do aporte em Token B Se o preço mudar > 2% durante o preenchimento: toast "O preço mudou. Proporção recalculada." e Token B se atualiza automaticamente.

Aprovações de token: Sub-label no CTA "(Aprovação necessária)" quando tokens precisam de aprovação. Sub-fluxo de T05 (Autorizar Tokens) ao avançar — idêntico ao fluxo principal. Aprovações já concedidas para este contrato LP em sessão anterior não precisam ser repetidas.

Resultado: O fluxo usa T06 como encerramento, com adaptações no headline e resumo:

Estado A (pendente): "Registrando adição à posição..." + "Aguardando confirmação na rede."
Estado B (sucesso): "Liquidez adicionada com sucesso" + "Adicionado à posição #NNNN · [USDC/ETH] · Concentrada" + valores adicionados + gas total pago
Estado C (erro): mesmo padrão de T06, com "Retomar adição" (em vez de "Retomar aporte") no CTA de recovery
CTA primário pós-sucesso: "Ver minha posição →" (navega para visualizar-posicao passando o ID da posição)
CTA secundário pós-sucesso: "Adicionar mais" (retorna para T08 com os campos zerados)

Posição encerrada (detectada ao carregar T08): Cenário improvável mas necessário: se a posição foi encerrada entre o clique em "Adicionar mais liquidez" e o carregamento de T08 (ex: outra aba do usuário encerrou a posição simultaneamente). Banner de erro: "Esta posição foi encerrada. Você não pode adicionar liquidez a uma posição fechada." CTAs: "Criar nova posição →" (vai para T01 com o par pré-selecionado) + "Ver minhas posições →".

4. Estados Não-Triviais

Loading (ao entrar em T08): Skeleton no mini-card. Skeleton nos campos de aporte (proporção sendo carregada). Se > 3s: "Carregando dados da posição..."

Posição in-range, nominal (modo Concentrada): Formulário direto. Badge ● verde. Sem banners. CTA dinâmico. Fluxo normal.

Posição out-of-range (modo Concentrada): Banner âmbar proeminente logo abaixo do mini-card. Formulário bloqueado (campos desabilitados com estado visual cinza) até ação explícita. CTA principal: "Ajustar a faixa →" (primário, não verde — é redirecionamento, não comprometimento financeiro) + "Adicionar mesmo assim" (laranja).

Posição Simples com proporção alterada: Mini-card exibe proporção atual. Campos de aporte funcionam com a proporção atual do pool. Nota informativa discreta: "Proporção atual: X%/Y% (diferente do aporte original)." Sem bloqueio — é informação, não risco crítico.

Saldo insuficiente (token específico): CTA laranja: "Saldo insuficiente em [Token A] · Comprar [Token A] →". Sub-label: "Você tem R$ XX,XX · Necessário: R$ YY,YY." O clique redireciona para T09 (on-ramp contextual) preservando os valores preenchidos.

Gas insuficiente: CTA laranja: "Saldo de gas insuficiente · Comprar [ETH / BNB] →". Sub-label: "Gas necessário: ~R$ XX,XX · Você tem: R$ YY,YY."

Aprovação necessária: Sub-label no CTA: "(Aprovação necessária)". Ao avançar: sub-fluxo T05, depois T06 adaptado.

Preço mudou durante preenchimento (> 2%): Toast: "O preço mudou. Proporção recalculada." Token B se atualiza com animação suave. Se > 5%: banner âmbar mais visível: "O preço de [Token A] mudou significativamente — verifique os valores antes de continuar."

Posição encerrada: Banner de erro vermelho cobrindo o formulário: "Esta posição foi encerrada — você não pode adicionar liquidez a uma posição fechada." CTAs: "Criar nova posição →" + "Ver minhas posições →".

Sucesso com posição fora da faixa após aporte: Estado B de T06 adaptado + banner âmbar adicional: "Você adicionou ao par fora da faixa atual — esta liquidez não renderá taxas até o preço retornar ao intervalo." CTA primário "Ver minha posição →" mantido como principal; link "Ajustar faixa →" como ação secundária.

5. Microcopy Crítico

Título da tela:

"Adicionar ao par [USDC/ETH]"

Indicador de contexto:

"Adicionando à posição #3847 · Concentrada em um intervalo · Taxa 0,3%"

Mini-card — badge dentro da faixa:

"● Dentro da faixa — você está ganhando taxas"

Mini-card — badge fora da faixa:

"● Fora da faixa — você não está ganhando taxas no momento"

Mini-card — faixa:

"Faixa: R$ 1.800,00 – R$ 2.400,00"

Mini-card — proporção Simples:

"Proporção atual do pool: 52% USDC / 48% ETH"

Mini-card — APR:

"~4,2% ao ano (estimativa 30d, sem Impermanent Loss) ⓘ"

Banner out-of-range:

"Sua posição está fora da faixa atual — adicionar liquidez aqui não renderá taxas até o preço retornar ao intervalo configurado." [Ajustar a faixa →] [Adicionar mesmo assim]

Nota persistente pós-"Adicionar mesmo assim":

"● Fora da faixa · Você optou por adicionar fora do intervalo atual."

Sub-label Token B — Concentrada:

"(Calculado com base na faixa da sua posição)"

Sub-label Token B — Simples:

"(Calculado automaticamente com base no preço atual)"

Nota de proporção alterada:

"Proporção atual do pool: 52% USDC / 48% ETH (diferente da proporção no seu aporte original)"

Card de custo:

"Total a adicionar: R$ X.XXX,XX" "Gas estimado: ~R$ XX,XX · [Atualizar ↻]" "Você paga agora: R$ X.XXX,XX" "O total adicionado permanece seu na posição — o gas é cobrado separadamente pela rede."

CTA sequência:

"Inserir valores" → "Revisar adição" → "Confirmar adição"

CTA — saldo insuficiente:

"Saldo insuficiente em [Token A] · Comprar [Token A] →"

CTA — gas insuficiente:

"Saldo de gas insuficiente · Comprar [ETH / BNB] →"

CTA — aprovação:

"Autorizar tokens e adicionar liquidez"

Preço recalculado:

"O preço mudou. Proporção recalculada."

Preço mudou muito:

"O preço de [Token A] mudou significativamente — verifique os valores antes de continuar."

Posição encerrada:

"Esta posição foi encerrada — não é possível adicionar liquidez a uma posição fechada." [Criar nova posição →] [Ver minhas posições →]

T06 adaptado — headline sucesso:

"Liquidez adicionada com sucesso"

T06 adaptado — resumo:

"Adicionado à posição #3847 · USDC/ETH · Concentrada em um intervalo" "Adicionado: X,XXXX USDC + X,XXXX ETH (≈ R$ X.XXX,XX)" "Gas total pago: R$ XX,XX"

T06 adaptado — CTA primário pós-sucesso:

"Ver minha posição →"

T06 adaptado — CTA secundário:

"Adicionar mais"

Botão de retorno:

"← Voltar à posição"

6. Rastreabilidade Obrigatória

🟢 Herdado

Mini-card sticky de identidade (posição específica, não health card genérico): padrão estabelecido em adicionar-liquidez-02, adicionar-liquidez-03, adicionar-liquidez-04, visualizar-posicao no design system Kotai — contexto da entidade nunca é perdido durante ação contextualizada.
APR com caveat obrigatório "~X% ao ano (estimativa 30d, sem IL) ⓘ": padrão obrigatório cross-fluxo do design system Kotai.
CTA dinâmico com label de obstáculo específico: [pancake-final § Transparência proativa antes do CTA] — padrão cross-fluxo do design system Kotai.
Linha-soma fechada "Total a adicionar / Gas / Você paga agora": padrão estabelecido em criar-pool-03, adicionar-liquidez-02/03/04 do design system Kotai.
Aprovação como sub-fluxo de T05 (não erro de recuperação): padrão estabelecido no design system Kotai desde criar-pool-04.
Resultado usa T06 com adaptação de copy (não cria nova tela de resultado): reutilização do componente de resultado já especificado — coerência narrativa do fluxo, sem duplicação de tela.
Defesa em camadas para posição out-of-range (confirmação explícita antes de aporte fora do intervalo): [pancake-final § Pilar 3 — Defesa em camadas + Hierarquia de toggle] — ação com risco financeiro não-trivial exige confirmação consciente, não apenas aviso passável.
Estado de "preço mudou" com recalculo e toast: padrão estabelecido em adicionar-liquidez-03 do design system Kotai.

🔴 Corrige

Banner out-of-range com ação explícita exigida (não aviso passável): corrige padrão da indústria — Uniswap e PancakeSwap permitem adição a posição concentrada fora da faixa sem confirmação explícita do usuário (estado crítico ausente da janela de decisão, análogo a [uniswap-nova-posicao.md § Fricção 2 — Ausência de estado do pool destino na janela de decisão]). O formulário bloqueado vai além do aviso passável — sem confirmação forçada, o usuário que não lê o banner comete erro financeiro real (capital não rende até o preço retornar). A regra específica de bloqueio está fundamentada em [pancake-final § Pilar 3 — Defesa em camadas] e detalhada no bloco ⚪.
Indicador de contexto condensado (sem stepper de 3 passos) — fluxo correto para sub-tarefas de uma posição existente: corrige a tendência de aplicar o stepper de "Par e modo / Configurar / Confirmar" em contextos onde o usuário não está criando uma posição nova. O stepper de T01-T04 é para criação; para aumento, o indicador compacto comunica o contexto sem implicar que o usuário está recomeçando o fluxo.
Nota de proporção alterada (Simples) informada antes de aportar: corrige [uniswap-nova-posicao.md § Fricção 2 — Ausência de estado do pool destino na janela de decisão] — usuário que aumenta posição em pool com proporção diferente do aporte original precisa saber que os valores calculados refletem a proporção atual, não a original.

🟡 Captura

CTA "Ajustar a faixa →" contextual para posição out-of-range: derivado de [uniswap-nova-posicao.md § Oportunidade 2 — Card de pré-visualização do pool destino] + [pancake-final § Pilar 4 — Educação contextual no ponto de decisão]. Nenhum DEX analisado entrega a ação "Ajustar faixa" dentro do contexto de adicionar liquidez a uma posição existente — o usuário precisaria sair do fluxo, navegar para visualizar-posicao, encontrar a ação de ajuste, e voltar. O CTA contextual elimina esse desvio. Hipótese: usuário que vê "Ajustar a faixa →" antes de adicionar capital a uma posição fora do range tem taxa de ajuste de range maior, reduzindo capital ocioso.
Reutilização de T05 e T06 para sub-fluxo de aumento: [uniswap-nova-posicao.md § Insight 1 — Stepper pedagógico e contextual] + princípio de coerência de design system. O usuário que já fez o fluxo completo (T01-T06) e retorna para "Adicionar mais" reconhece a tela de revisão e a tela de resultado — reduz cognitive load por familiaridade. Hipótese: taxa de conclusão de "adicionar mais" é maior quando o resultado é o T06 conhecido do que quando é uma tela nova.

⚪ Novo

Formulário de aporte bloqueado até ação consciente na posição out-of-range: sem precedente direto nos consolidados como regra de negócio explicitada. Justificativa: o padrão de indústria (Uniswap e PancakeSwap) permite adicionar liquidez a uma posição concentrada fora do range sem aviso explícito — o usuário descobre depois que o capital não rende. A defesa aqui vai além do aviso (que pode ser ignorado) para exigir ação consciente ("Adicionar mesmo assim") antes de liberar o formulário. Fundamentado em [pancake-final § Pilar 3 — Defesa em camadas] e em [pancake-final § Pilar 4 — Educação contextual no ponto de decisão], mas a regra específica de bloqueio do formulário é nova. Custo: lógica de estado que verifica in-range ao carregar T08, com polling de preço para manter atualizado. Evidência a coletar: taxa de clique em "Ajustar a faixa →" vs "Adicionar mesmo assim" — se > 40% ajusta a faixa antes de adicionar, o aviso está funcionando.
Indicador compacto de contexto substituindo stepper completo: sem precedente nos consolidados. Justificativa: usar o stepper de 3 passos (Par e modo / Configurar / Confirmar) em T08 implicaria que o usuário está num fluxo de 3 passos — o que não é verdade aqui (o par e modo já estão definidos). O indicador compacto "Adicionando à posição #3847 · Concentrada · Taxa 0,3%" comunica o contexto sem criar expectativa de passos adicionais de seleção. Custo: componente novo de "contexto de sub-fluxo" no design system. Evidência a coletar: taxa de confusão "achei que ia ter que reselecionar o par" via suporte.
Nota de proporção alterada para modo Simples: sem precedente nos consolidados. Justificativa: em pools V2 com muito uso, a proporção 50/50 original do usuário pode ter derivado para 70/30. O usuário que adiciona capital sem saber que a proporção mudou pode ser surpreendido pela quantidade de tokens calculada automaticamente. A nota "(diferente do aporte original)" é informação prevenindo surpresa, com custo de 1 linha de UI. Evidência a coletar: taxa de tickets de suporte "por que não está calculando 50/50 como da primeira vez?".

7. Trade-offs e Segunda Ordem

Estado out-of-range como bloqueio de formulário: Bloquear o formulário até ação consciente adiciona fricção real para o usuário que já sabe o que está fazendo (ex: usuário avançado que intencionalmente adiciona capital fora da faixa como estratégia de acumulação). Mitigação: "Adicionar mesmo assim" é um click distante do formulário (não um confirm modal), e o formulário fica acessível imediatamente após. O custo de fricção é baixo; o ganho de prevenção de erro iniciante é alto. Aceitar.

Polling de preço para manter o badge in/out-of-range atualizado: A posição pode passar de in-range para out-of-range durante o preenchimento do formulário se o preço se mover. Polling de preço a cada 30s é necessário para o badge estar correto. Em mobile com conexão fraca: pode causar re-render do mini-card. Mitigação: atualização do badge com animação suave (fade) e sem re-render do formulário. Se o polling falhar: badge exibe "Status da faixa não disponível" com timestamp do último dado.

Reutilização de T05/T06 com copy adaptado: Os componentes de T05 (autorização) e T06 (resultado) são reutilizados com adaptações de copy ("adicionado" vs "criado", "posição #NNNN" vs "posição nova"). Risco: inconsistência de copy se as adaptações não forem feitas sistematicamente. Mitigação: as strings dinâmicas de T05/T06 são parametrizadas por "contexto de sub-fluxo" (novo / adicionar) — não são hardcoded. O componente de T06 já é parametrizável (headline, sub-headline, CTA por estado).

Dois CTAs no banner out-of-range: Dois botões de ação ("Ajustar a faixa →" + "Adicionar mesmo assim") podem criar paralisia de escolha. Mitigação: hierarquia clara — "Ajustar a faixa →" como primário (brand color, não verde) e "Adicionar mesmo assim" como ação de override (laranja). A cor laranja já é estabelecida no design system como sinal de "caminho de risco entendido".

i18n: Microcopy de estado da posição (in-range / out-of-range / ID / faixa) são interpolados — 8–10 strings dinâmicas por idioma. Custo real especialmente quando novos modos de LP forem adicionados. Componente mini-card de posição com props de conteúdo — não hardcoded.

Adicionar Liquidez — Tela 09: On-Ramp Contextual — Comprar Tokens para o Aporte

1. Função da tela

Bottom sheet / modal lateral contextual que aparece quando o usuário em T02 ou T03 está com saldo insuficiente de um ou ambos os tokens do par LP, oferecendo três caminhos de resolução sem abandonar o fluxo de aporte: compra com reais via PIX ou cartão (PIX-first para BR/LatAm), troca de outro token na carteira, ou instrução de transferência da exchange. Ao ser resolvido, retorna automaticamente ao formulário com o saldo atualizado. Foco: iniciante BR/LatAm sem cripto mas com intenção real de aportar, que de outra forma abandonaria o fluxo por falta de saldo sem saber que tem caminhos de resolução dentro do produto.

2. Componentes / Elementos

Estruturais (definem o paradigma da tela)

a) Contexto preservado — formulário visível atrás do modal O formulário de T02 ou T03 permanece visível (e legível, sem overlay opaco) atrás do bottom sheet, em mobile de forma semi-visível acima do sheet e em desktop como modal lateral. O usuário não "sai" do fluxo de aporte — a compra é uma resolução de obstáculo, não um desvio. Esta decisão arquitetural é o princípio mais importante desta tela: o contexto do aporte (par, modo, valores inseridos) nunca é destruído.

b) Header do bottom sheet "Comprar [Token A] para o aporte"

Sub-label contextual dinâmico:

"Você tem R$ XX,XX de [Token A] — precisa de pelo menos R$ X.XXX,XX para este aporte."

Botão × no canto direito (fecha o sheet, retorna para T02/T03 com os valores preservados, sem compra iniciada). Botão × é sempre disponível — não forçar a compra.

c) Tabs de método (estrutural — organização do conteúdo por caminho de resolução) Três tabs horizontais, com a relevante para o contexto ativa por default:

"Comprar com reais" (ativa por default para usuário BR com locale detectado)
"Trocar tokens" (ativa apenas quando o usuário tem saldo > 0 em outro token na carteira)
"Transferir da exchange" (sempre disponível)

Aba "Comprar com reais" (default para locale PT-BR)

d) Campo de valor de compra Label: "Quanto comprar (em reais)" Pré-preenchido com o delta calculado: (valor necessário − saldo disponível) × 1,10, arredondado para cima para o real inteiro. A margem de 10% absorve variação de preço entre o momento do cálculo e a chegada da cripto na carteira. Sub-label: "Calculado com base no seu aporte · você pode ajustar" Campo editável — o usuário pode comprar mais ou menos do que o sugerido.

e) Seletor de provider (componente central da aba) Lista de 3–4 providers de on-ramp ordenados por quantidade de [Token A] recebida (não por taxa isolada — o iniciante entende "você recebe mais USDC" mais do que "taxa menor"). Cada linha de provider:

Logo do provider + nome
Linha principal: "Você recebe X,XXXX [Token A]"
Linha secundária: "Você paga R$ X.XXX,XX · Taxa do provider + Taxa Kotai"
Ícone de método de pagamento: "PIX" / "Cartão" / "Boleto" como chip discreto

Ordenação e destaques:

Provider com mais tokens recebidos = topo da lista + badge "Melhor cotação agora ✓"
Provider com PIX: badge adicional "● PIX · Mais rápido" para usuário BR (geo-default)
Se o mesmo provider for o melhor cotação E oferecer PIX: badge único "Melhor cotação · PIX ✓"
Provider pré-selecionado = o de maior quantidade de [Token A] recebida (padrão herdado do fluxo comprar do Pancake: provider de "Melhor cotação" pré-selecionado, critério explícito)

f) Nota de transparência e segurança Abaixo do seletor de providers, discreta:

"Compra processada por [Provider] — a Kotai não processa pagamentos diretamente. Taxa Kotai: X% incluída na cotação acima."

g) CTA da aba "Comprar com reais" "Ir para compra →" (abre o provider selecionado em webview in-app em mobile ou nova aba em desktop)

Aba "Trocar tokens"

h) Seletor de token de origem Label: "Qual token você tem?" Dropdown com apenas os tokens que o usuário tem na carteira com saldo > 0, excluindo os tokens do par do aporte (não faz sentido trocar Token A por Token A). Se nenhum token elegível estiver disponível: aba oculta do seletor de tabs.

Preview dinâmico após seleção do token de origem:

"Taxa de câmbio: 1 [Token X] ≈ Y,YYYY [Token A]"
"Você recebe aproximadamente X,XXXX [Token A]" (baseado no saldo do token de origem)
"Slippage estimado: ~Z%"

i) CTA da aba "Trocar tokens" "Ir para Trocar →" — abre o fluxo de Swap com Token X (origem) e Token A (destino) pré-selecionados, com o valor de saída aproximado como sugestão. Ao completar o swap e retornar, T09 detecta o saldo atualizado.

Aba "Transferir da exchange"

j) Instrução de transferência Label: "Seu endereço · [Nome da Rede]"

Endereço hex truncado: 0xAB12...CD34
Badge de rede proeminente: "BNB Chain" / "Ethereum" / "[Nome da Rede]" — nunca apenas o hex sem identificador de rede
Botão de cópia ⬡ e botão QR Code
Sub-label: "Envie [Token A] para este endereço na rede [Nome da Rede]."

Aviso de rede obrigatório:

"⚠ Certifique-se de enviar na rede [Nome da Rede] — enviar em outra rede pode resultar em perda permanente dos tokens."

Link pedagógico: "Como transferir da Binance para esta carteira →" (abre conteúdo educacional in-app ou, se não disponível, link externo em nova aba)

Nota de tempo: "A transferência pode levar alguns minutos para ser confirmada na rede."

Cosméticos

Timestamp de atualização da cotação: "Cotação atualizada há N min · [Atualizar ↻]"
Separador visual entre o header e as tabs
Indicador de loading inline no campo de valor enquanto cotação é calculada (não spinner de tela cheia)
Link "Ver detalhes do aporte que você está configurando →" no header (expande o formulário de T02/T03 temporariamente para revisão)

3. Regras de Negócio

Pré-cálculo do valor sugerido: Ao abrir T09, calcular: max(0, valor_necessário_token_a − saldo_disponível_token_a) × 1.10, arredondado para cima. Se o usuário precisar dos dois tokens (ambos com saldo insuficiente): mostrar T09 para o token com maior déficit percentual primeiro; após resolução, re-verificar o segundo token e abrir T09 novamente se ainda insuficiente. Não tentar resolver os dois simultaneamente — uma compra de cada vez.

Geo-default para locale PT-BR: Aba "Comprar com reais" é a default e a aba ativa ao abrir T09 para usuário com locale PT-BR detectado. PIX aparece como método de destaque. Para outros locales: aba "Comprar com reais" ainda está disponível, mas sem destaque de PIX; o método de pagamento primário muda conforme o locale (SEPA para Europa, ACH para EUA).

Tab "Trocar tokens" — visibilidade condicional: A tab só aparece se o usuário tem pelo menos um token com saldo > 0 na carteira conectada, excluindo os tokens do par atual. Se nenhum token elegível: tab "Trocar tokens" oculta (não desabilitada com estado cinza — simplesmente não renderizada).

Cotação e atualização: A cotação de on-ramp tem TTL de 60s. Após TTL: badge âmbar "Cotação pode ter mudado · [Atualizar ↻]" e campo de "Você recebe" exibe "(cotação desatualizada)". O CTA "Ir para compra →" permanece habilitado — o provider recalcula a cotação no momento da execução.

Retorno após compra concluída: Quando o usuário retorna do provider (in-app webview fechado ou nova aba fechada): T09 inicia polling de saldo a cada 15s por até 5 minutos. Se o saldo atualizar: T09 fecha automaticamente + toast em T02/T03: "Saldo de [Token A] atualizado. Verifique o valor e continue." Se o saldo não atualizar em 5 minutos: toast "A compra pode ainda estar sendo processada — aguarde ou verifique o status no provider." + botão "Verificar saldo agora" para polling manual.

Retorno após compra iniciada mas não concluída: Se o usuário retornar sem completar a compra (fechou o webview no meio): T09 permanece aberto no estado da aba onde estava. Sem toast de "compra cancelada" — o usuário pode ter apenas pausado. Se o saldo não mudar em 30s após retorno: volta ao estado de espera passiva (sem polling ativo).

Fechamento via × sem compra: Retorna para T02/T03 com todos os valores e o estado de "Saldo insuficiente" preservados — o CTA de T02/T03 ainda mostra "Saldo insuficiente em [Token A] · Comprar [Token A] →". O usuário não perdeu nada; pode tentar de novo mais tarde.

Wallet de contrato (smart wallet/MPC): Aba "Transferir da exchange" exibe nota adicional: "Algumas exchanges não permitem enviar para endereços de contrato. Verifique com sua exchange antes de enviar." Badge discreto no endereço: "Contrato · [Nome da Rede]".

4. Estados Não-Triviais

Loading de cotação (ao abrir a aba "Comprar com reais"): Skeleton nos cards de provider. Sub-label no campo de valor: "(Calculando cotação...)" Se > 3s: "Buscando melhores cotações... pode levar alguns segundos."

Erro de cotação — provider offline: Card do provider com badge cinza "Cotação indisponível — tente outro provider". Se todos os providers offline: mensagem central: "Não foi possível carregar cotações. Verifique sua conexão ou use as abas Trocar tokens ou Transferir da exchange."

Cotação desatualizada (> 60s sem refresh): Badge âmbar "Cotação pode ter mudado · [Atualizar ↻]" no seletor. Campo de quantidade exibe "(cotação desatualizada)" ao lado do valor. CTA "Ir para compra →" mantido habilitado.

Compra concluída — saldo atualizado: Polling detectou saldo novo. T09 fecha com animação de colapso. Toast em T02/T03:

"✓ Saldo de [Token A] atualizado. Verifique o valor e continue." O CTA de T02/T03 muda automaticamente de "Saldo insuficiente" para o próximo passo do fluxo.

Compra iniciada — saldo ainda não confirmado: Polling de 5 min sem detecção de saldo novo. Toast:

"A compra pode ainda estar sendo processada. Aguarde ou verifique o status no provider." Botão "Verificar saldo agora" para polling manual.

Tab "Trocar tokens" — sem tokens elegíveis: Tab não renderizada (não está presente no seletor de tabs). Se o usuário chegar em T09 com carteira sem tokens, apenas as abas "Comprar com reais" e "Transferir da exchange" estão visíveis.

Rede errada detectada (usuário em Ethereum, par na BNB Chain): Banner âmbar no header do sheet:

"⚠ Você está na rede Ethereum, mas este par está na BNB Chain. Troque de rede antes de transferir." Link: "Trocar para BNB Chain →"

Ambos os tokens com saldo insuficiente: T09 abre para o token com maior déficit percentual (Token A). Após resolução de Token A: ao retornar para T02/T03, se Token B ainda insuficiente: toast "Saldo de [Token A] ok! Agora você precisa de mais [Token B]." + reabre T09 automaticamente para Token B. Não tentar resolver ambos em uma única sessão de T09 — um passo de cada vez.

5. Microcopy Crítico

Título do bottom sheet:

"Comprar [Token A] para o aporte"

Sub-label contextual:

"Você tem R$ XX,XX de [Token A] — precisa de pelo menos R$ X.XXX,XX para este aporte."

Labels das tabs:

"Comprar com reais" / "Trocar tokens" / "Transferir da exchange"

Campo de valor:

"Quanto comprar (em reais)" "Calculado com base no seu aporte · você pode ajustar"

Badge de melhor cotação:

"Melhor cotação agora ✓"

Badge PIX:

"● PIX · Mais rápido"

Badge combinado:

"Melhor cotação · PIX ✓"

Linha de comparação de provider:

"Você recebe X,XXXX [Token A]"

Linha secundária de provider:

"Você paga R$ X.XXX,XX · Taxa do provider + Taxa Kotai"

Nota de transparência:

"Compra processada por [Provider] — a Kotai não processa pagamentos diretamente. Taxa Kotai: X% incluída na cotação."

CTA — aba "Comprar com reais":

"Ir para compra →"

Cotação desatualizada:

"Cotação pode ter mudado · [Atualizar ↻]"

Timestamp:

"Cotação atualizada há N min"

Aba "Trocar tokens" — seletor:

"Qual token você tem?"

Aba "Trocar tokens" — preview:

"Taxa de câmbio: 1 [ETH] ≈ 2.358,00 USDC" "Você recebe aproximadamente X,XXXX USDC"

CTA — aba "Trocar tokens":

"Ir para Trocar →"

Aba "Transferir da exchange" — label endereço:

"Seu endereço · BNB Chain"

Aba "Transferir da exchange" — aviso de rede:

"⚠ Certifique-se de enviar na rede BNB Chain — enviar em outra rede pode resultar em perda permanente dos tokens."

Link pedagógico:

"Como transferir da Binance para esta carteira →"

Nota de tempo:

"A transferência pode levar alguns minutos para ser confirmada na rede."

Toast — compra concluída:

"✓ Saldo de [Token A] atualizado. Verifique o valor e continue."

Toast — compra em andamento:

"A compra pode ainda estar sendo processada. Aguarde ou verifique o status no provider."

Botão de verificação manual:

"Verificar saldo agora"

Banner — rede errada:

"⚠ Você está na rede Ethereum, mas este par está na BNB Chain. Troque de rede antes de transferir." [Trocar para BNB Chain →]

Providers offline:

"Não foi possível carregar cotações. Verifique sua conexão ou use as abas Trocar tokens ou Transferir da exchange."

Wallet de contrato — nota:

"Algumas exchanges não permitem enviar para endereços de contrato. Verifique com sua exchange antes de enviar."

Segundo token insuficiente (após resolver o primeiro):

"Saldo de [Token A] atualizado! Agora você precisa de mais [Token B] para completar o aporte."

6. Rastreabilidade Obrigatória

🟢 Herdado

Provider de "Melhor cotação" pré-selecionado com critério explícito (quantidade de cripto recebida como unidade central de comparação): [pancake-final § Transparência proativa antes do CTA (parcial)] + [pancake-comprar § provider melhor cotação pré-selecionado com critério visível] — o iniciante entende "você recebe mais USDC" mais facilmente do que "taxa menor"; output em cripto como unidade de comparação é o padrão correto para contexto DeFi.
Defaults pró-iniciante sem pedir permissão: [pancake-final § Defaults pró-iniciante sem pedir permissão] — PIX pré-selecionado para locale PT-BR, aba "Comprar com reais" ativa por default, provider de melhor cotação já selecionado. O usuário avançado pode trocar; o iniciante recebe o caminho correto sem precisar configurar.
Contexto preservado — formulário visível atrás do modal: [uniswap-final § Progressive disclosure como padrão arquitetural, não recurso pontual] + [uniswap-final § Ação imediata sem commit nem onboarding] — o sub-fluxo de compra não destrói o contexto do fluxo-pai; o usuário retorna exatamente de onde saiu.
Tab "Trocar tokens" — apenas quando há tokens elegíveis: [pancake-adicionar-liquidez.md § Insight 1 — Adaptação honesta do formulário ao protocolo] — não renderizar opção que não existe para aquela configuração; tab oculta (não desabilitada) quando não há tokens elegíveis.
Badge de rede no endereço de transferência (nunca apenas hex): [pancake-final § Fricção 4 — Endereço sem identificador de rede no momento de saída] — a fricção 4 do Pancake é exatamente a ausência de badge de rede no endereço; T09 a resolve no único ponto do fluxo de LP onde o usuário pode precisar de um endereço para receber.
Geo-default por locale/IP: Pilar 2 Kotai (defaults em 4 camadas, geo-default por locale/IP) + [uniswap-final § Fricção 4 — Defaults ignoram contexto que o sistema já tem] (a Uniswap não usa locale detectado; a Kotai usa como default da primeira camada).

🔴 Corrige

On-ramp local-first (PIX/CEX BR) em vez de Moonpay/Coinbase como default: corrige [uniswap-final § Fricção 4 — Defaults ignoram contexto que o sistema já tem] (Uniswap aponta Moonpay/Coinbase para usuário BR sem considerar o contexto local) + [pancake-final § Pilar 5 — Mobile-first interaction + Localização BR/LatAm como infraestrutura] (PIX/CEX BR como infraestrutura, não feature opcional).
Aviso de rede obrigatório antes de copiar o endereço (não após): corrige [pancake-final § Fricção 4 — Endereço sem identificador de rede no momento de saída] — a posição do aviso importa: exibir após a cópia já é tarde se o usuário não leu; o aviso antes do endereço muda a ordem de leitura.
Nota de transparência da taxa do provider e da taxa Kotai: corrige [pancake-final § Fricção 1 — Léxico de protocolo como vocabulário primário] aplicado ao contexto de on-ramp — "Provider Fees" e "Pancake Fees" em inglês no breakdown do Pancake são o padrão que a Kotai resolve com breakdown em PT-BR + taxa explicitada.
Sub-label dinâmico que quantifica o déficit em reais: corrige [uniswap-nova-posicao.md § Fricção 2 — Ausência de estado do pool destino na janela de decisão] por simetria — assim como o usuário precisa ver o estado do pool antes de aportar, precisa ver o quantum do déficit antes de comprar. "Você tem R$ XX,XX — precisa de R$ X.XXX,XX" é a informação que torna a compra concreta, não abstrata.

🟡 Captura

Resolução de saldo insuficiente dentro do fluxo de LP (não redirecionamento externo): [pancake-final § Pilar 5 — Mobile-first interaction + Localização BR/LatAm como infraestrutura] — on-ramp como infraestrutura do produto, não como link externo. Hipótese: usuário que resolve o saldo insuficiente dentro do fluxo de Adicionar Liquidez tem taxa de retorno ao formulário maior do que usuário redirecionado para uma tela de "Comprar" genérica, que perde o contexto do par e dos valores inseridos.
PIX como método de pagamento primário para BR/LatAm: [pancake-final § Pilar 5 — Localização BR/LatAm como infraestrutura]. A diferenciação concreta é: o produto não apenas suporta PIX, mas o coloca no topo da lista e o marca como "Mais rápido" para o usuário BR. Hipótese: usuário BR que vê "PIX · Mais rápido" como primeira opção tem menor abandono no on-ramp do que usuário que precisa rolar para encontrar o PIX entre métodos internacionais.
Pré-cálculo automático com margem de 10% para absorver variação de preço: derivado de [uniswap-nova-posicao.md § Oportunidade 3 — Slippage adaptativo ao par/pool] por analogia — o mesmo princípio de "calcular automaticamente o parâmetro ótimo" se aplica ao valor de compra sugerido. Hipótese: usuário que compra o pré-calculado + 10% não precisa repetir o processo porque comprou a menos.

⚪ Novo

Polling automático de saldo após retorno do provider (sem refresh manual): sem precedente direto nos consolidados. Justificativa: o usuário que completa uma compra no provider externo e retorna ao app não deve precisar "pressionar refresh" para ver o saldo atualizado — a atualização automática é a expectativa natural e a ausência dela cria confusão ("a compra funcionou?"). Custo: polling de saldo a cada 15s por até 5 minutos após retorno — custo de API real, mas baixo em termos de frequência. TTL de 5 minutos cobre a maioria dos on-ramps (confirmação PIX em < 3 min na prática). Evidência a coletar: taxa de "minha compra não apareceu" em suporte antes/depois do polling automático.
Resolução sequencial de dois tokens insuficientes (um de cada vez, não simultânea): sem precedente nos consolidados. Justificativa: tentar resolver dois déficits simultaneamente (abrir dois on-ramps, um para Token A e outro para Token B) aumenta cognitive load e risco de erro de valor. A abordagem sequencial — resolve Token A, retorna, verifica Token B — é mais controlada e menos propensa a erro de compra. Custo: lógica de re-verificação de saldo após resolução do primeiro token + abertura condicional de T09 para o segundo. Evidência a coletar: taxa de "comprei o token errado" em suporte — se alto, indica que a sequência ainda confunde.
Margem de 10% no pré-cálculo do valor sugerido: sem precedente nos consolidados como regra explícita de cálculo. Justificativa: on-ramps têm slippage de cotação entre o momento de visualização e a execução; comprar exatamente o necessário frequentemente resulta em déficit residual. A margem de 10% é conservadora o suficiente para cobrir variações típicas de preço em 5–10 minutos de on-ramp, sem forçar compra excessiva. Evidência a coletar: taxa de "ainda falta saldo depois da compra" — se > 5%, aumentar a margem para 15%.

7. Trade-offs e Segunda Ordem

Contexto preservado atrás do modal: Manter T02/T03 visível atrás do bottom sheet requer que o formulário permaneça montado em memória durante a sessão de T09. Em mobile de baixo custo com pouca RAM, isso pode causar reload do formulário ao retornar. Mitigação: persistência local dos valores do formulário (localStorage ou estado de sessão) — em caso de reload do formulário ao retornar, os valores são restaurados automaticamente.

Polling de saldo pós-compra (custo de API): Polling de saldo a cada 15s por 5 minutos = até 20 chamadas de API por sessão de compra. Para produtos com muitos usuários simultâneos em on-ramp, isso pode ser caro. Mitigação: exponential backoff (15s → 30s → 60s) após o primeiro minuto sem detecção de saldo; cancelamento do polling se o usuário fechar T09 ou T02/T03.

Pré-cálculo com margem de 10% pode forçar compra excessiva: O usuário com exatamente R$ 1.000,00 disponíveis e déficit de R$ 950,00 receberá sugestão de R$ 1.045,00 — acima do seu limite. O campo é editável e o sub-label deixa claro que é sugestão, mas o valor pré-preenchido pode frustrar quem não pode comprar mais do que o necessário. Mitigação: verificar se o pré-calculado com margem excede algum limite implícito do usuário (difícil de detectar sem KYC). Aceitar o risco — a margem beneficia mais casos do que prejudica.

Tab "Trocar tokens" esconde complexidade: A troca de tokens para resolver o déficit de LP esconde o fato de que o swap tem seu próprio slippage e custo de gas — o usuário pode trocar Token X por Token A e acabar com menos Token A do que esperava, retornando ao estado de saldo insuficiente. Mitigação: o preview dinâmico da aba "Trocar tokens" exibe a quantidade estimada de Token A com aviso de slippage. Sub-label: "Valor estimado — o slippage pode reduzir a quantidade recebida." Não bloquear — apenas informar.

Aviso de rede na aba "Transferir da exchange" pode ser ignorado: O aviso "Certifique-se de enviar na rede BNB Chain" é informação crítica mas pode sofrer de banner blindness. Mitigação: o aviso está posicionado antes do endereço (não depois) e usa o ícone ⚠ em âmbar. Para wallets EOA, considerar adicionar o nome da rede como parte do QR Code de endereço para que o provider de CEX que escaneia também veja a rede. Implementação futura — não bloqueia o MVP.

i18n e localização de providers: O seletor de providers precisa exibir providers relevantes por região — PIX é BR-exclusivo; SEPA é Europa; ACH é EUA. A lista de providers não é global. Custo: localização do seletor de providers por locale/região detectada, com fallback para lista global quando região não reconhecida. Este custo é o maior deste componente — o seletor de on-ramp é a parte mais cara de manter a longo prazo à medida que providers entram e saem do mercado.

proposta/visualizar-pool/visualizar-pool-01.png

proposta/visualizar-pool/visualizar-pool-02.png

proposta/visualizar-pool/visualizar-pool-03.png

proposta/visualizar-pool/visualizar-pool-04.png

proposta/visualizar-pool/visualizar-pool-05.png

proposta/visualizar-pool/visualizar-pool-06.png

proposta/adicionar-liquidez/adicionar-liquidez-04.png

proposta/adicionar-liquidez/adicionar-liquidez-05.png

proposta/adicionar-liquidez/adicionar-liquidez-06.png

proposta/adicionar-liquidez/adicionar-liquidez-01.png

proposta/adicionar-liquidez/adicionar-liquidez-02.png

proposta/adicionar-liquidez/adicionar-liquidez-03.png

proposta/adicionar-liquidez/adicionar-liquidez-07.png

proposta/adicionar-liquidez/adicionar-liquidez-08.png

proposta/adicionar-liquidez/adicionar-liquidez-09.png

proposta/suas-posicoes/suas-posicoes-01.png

proposta/suas-posicoes/suas-posicoes-02.png

proposta/suas-posicoes/suas-posicoes-03.png

proposta/suas-posicoes/suas-posicoes-04.png

proposta/suas-posicoes/suas-posicoes-05.png

proposta/suas-posicoes/suas-posicoes-06.png