Arquitetura

Visão Geral

FlareWatch é uma aplicação Next.js que monitora e rastreia posições na Flare Network — staking, delegação, recompensas e rendimento. O fato arquitetônico definidor é que ela é somente leitura: não há banco de dados backend armazenando o estado financeiro do usuário, nenhum caminho de assinatura de transações e nenhum acesso programático às chaves do usuário. Todos os dados de posição são obtidos da infraestrutura on-chain do Flare no momento da requisição.

A conexão da carteira (Sign-In-With-Ethereum) existe apenas para identificar qual endereço on-chain consultar. Ela não autoriza ações on-chain porque a aplicação não possui ações on-chain para autorizar.

O que FlareWatch lê e de onde

Cada endereço de contrato usado pelo FlareWatch é resolvido em tempo de execução a partir do FlareContractRegistry, o registro de endereço on-chain canônico do Flare (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). Quando a governança do Flare move um contrato, FlareWatch utiliza o novo endereço na próxima sessão sem uma mudança de código.

Fontes de dados, em ordem de prioridade:

• On-chain (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — fonte de verdade para saldos, stakes, recompensas reclamáveis e preços.
• Flaremetrics API — metadados de validador e provedor FTSO muito caros para serem computados no lado do cliente.
• CoinGecko — dados de preços multi-moeda e capitalização de mercado.
• Flare Block Explorer — pesquisas de transações históricas para registros fiscais e classificação de recompensas.

Fluxo de dados em camadas

A aplicação impõe uma regra de camadas de direção única rigorosa:

services → stores → hooks → components → pages

O efeito prático é que busca, derivação e renderização têm um único local. Um componente que precisa de dados de validador se inscreve no estado do validador — nunca chama a API Flaremetrics diretamente.

Fluxos de recompensas

FlareWatch rastreia quatro fluxos de recompensa independentes. Tratar qualquer um deles como um único pool causa contagem significativa de rendimento incorreta, é por isso que cada um é originado e computado separadamente.

O principal em stake da P-Chain é devolvido ao desbloqueio e não é um fluxo de recompensas, mesmo que apareça nos saldos da conta.

Estimativa de rendimento

FlareWatch utiliza um modelo de rendimento em três níveis. Cada nível é rotulado na interface para que o usuário compreenda a precisão da estimativa.

• Nível 1 — Verdade estabelecida. Recompensas exigíveis on-chain via contrato RewardManager. Este é um valor real na blockchain, aguardando para ser resgatado.
• Nível 2 — Baseado em dados. Quando o valor exigível é zero, FlareWatch utiliza a mediana dos últimos cinco resgates do histórico de transações da carteira como estimativa para a próxima época.
• Nível 3 — Fallback de fórmula. Quando não existe histórico de resgates, saldoWflr × FTSO_DELEGATION_APR / epochsPerYear projeta uma taxa matemática baseada no estado atual da rede.

FlareWatch mostra um único APY para staking nativo Flare e delegação FTSO: o pagamento da última época de recompensa por FLR após taxas, anualizado (× 365 / 3,5 dias). Não é composto, porque recompensas Flare devem ser resgatadas antes de poderem gerar, e corresponde à figura que outros exploradores Flare publicam. Posições DeFi que auto-componem (como Sceptre sFLR) mostram seu próprio APY de protocolo.

Modelo de segurança — visão geral

A segurança é abordada em detalhes na página de Recursos de Segurança. Os pontos principais são:

• Identidade baseada em carteira, não em contas. Sem senhas, sem identidade vinculada a email. A conexão da carteira identifica qual endereço consultar.
• Somente leitura por design. O app nunca mantém chaves, nunca assina transações e nunca interage com contratos inteligentes em nome do usuário.
• Revogação de sessão no lado do servidor. A desconexão é imposta no servidor, portanto um cookie de sessão roubado deixa de funcionar assim que o usuário faz logout — não na expiração de 24 horas.
• Controle de propriedade por carteira. Cada rota de API que lê ou escreve estado por carteira verifica que a carteira autenticada corresponde à carteira de destino. Não há caminho de override de administrador para dados do usuário.
• Cabeçalhos HTTP em defesa em profundidade. Strict-Transport-Security, uma Content-Security-Policy restritiva, X-Frame-Options DENY e uma Permissions-Policy rigorosa vêm em cada resposta.

Testes

O aplicativo é testado como se toda regressão fosse acontecer — porque os tipos de regressão que FlareWatch se importa (cálculos financeiros sutilmente errados) são silenciosos quando são enviados. Áreas de cobertura:

• Matemática de APY de staking e delegação FTSO.
• Formatação de moeda em múltiplas jurisdições.
• Formatação de valor FLR, percentual e data.
• Lógica de banda de cor de limite (para que uma entrega "verde" nunca mude silenciosamente para âmbar).
• Computações de prazos fiscais em jurisdições.

A suite de testes é executada em CI a cada push.

Infraestrutura

O FlareWatch é executado no Vercel. O frontend, os cron jobs que aquecem caches e o armazenamento de chave-valor com suporte em Redis que armazena esses caches compartilham a plataforma. A escolha é deliberada: custo operacional zero em escala e toda a superfície de implantação é auditável através de um único provedor.

A camada services/ é intencionalmente agnóstica a framework. Se o FlareWatch migrar do Vercel, os serviços de lógica de negócio são funções async puras e se movem com ele.

Leitura adicional

• Recursos de Segurança — autenticação, autorização, limitação de taxa, headers, histórico de auditoria.
• Visão Geral de Salvaguardas — as regras arquiteturais que o FlareWatch impõe a si mesmo, e por quê.