Descripción general
FlareWatch es una aplicación Next.js que monitorea y rastrea posiciones en Flare Network — staking, delegación, recompensas y rendimiento. El hecho arquitectónico definitorio es que es de solo lectura: no hay base de datos de backend que mantenga el estado financiero del usuario, no hay ruta de firma de transacciones y no hay acceso programático a las claves del usuario. Todos los datos de posición se obtienen de la infraestructura en cadena de Flare en el momento de la solicitud.
La conexión de billetera (Sign-In-With-Ethereum) existe únicamente para identificar qué dirección en cadena consultar. No autoriza acciones en cadena porque la aplicación no tiene acciones en cadena que autorizar.
Qué lee FlareWatch y de dónde
Cada dirección de contrato utilizada por FlareWatch se resuelve en tiempo de ejecución desde FlareContractRegistry, el registro canónico de direcciones en cadena de Flare (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). Cuando la gobernanza de Flare mueve un contrato, FlareWatch adopta la nueva dirección en la siguiente sesión sin cambios de código.
Fuentes de datos, en orden de prioridad:
- En cadena (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — fuente de verdad para saldos, stakes, recompensas reclamables y precios.
- API de Flaremetrics — metadatos de validadores y proveedores FTSO que son demasiado costosos de calcular en el lado del cliente.
- CoinGecko — datos de precios multimoneda y capitalización de mercado.
- Flare Block Explorer — búsquedas históricas de transacciones para registros fiscales y clasificación de recompensas.
Flujo de datos en capas
La aplicación aplica una regla de capas unidireccional estricta:
services → stores → hooks → components → pages
| Capa | Responsabilidad |
|---|---|
| Servicios | Lógica de negocio y obtención de datos. Funciones puras asincrónicas. Sin React. |
| Almacenes | Estado reactivo (Zustand). Contiene datos, sin obtención. |
| Hooks | Capa de conexión. Llama a servicios, escribe en stores. Sin lógica de negocio. |
| Componentes | Lee desde stores mediante selectores. Renderiza UI. Nunca obtiene datos. |
| Páginas | Composición. Organiza componentes de funcionalidades. |
El efecto práctico es que la obtención, derivación y renderización cada una tienen un único lugar. Un componente que necesita datos de validador se suscribe al estado del validador — nunca llama a la API de Flaremetrics directamente.
Flujos de recompensas
FlareWatch rastrea cuatro flujos de recompensas independientes. Tratar cualquiera de estos como un único pool causa un conteo de rendimiento significativamente incorrecto, por lo que cada uno se obtiene y calcula por separado.
| Flujo | Cadencia | Vencimiento |
|---|---|---|
| Recompensas por delegación FTSO | Cada epoch de recompensas (~3,5 días) | ~87.5 days |
| Gestor de Recompensas de Validación (VRM) | Cada 4 epochs de recompensas (~14 días) | Nunca |
| Stake reflejado (P-Chain → FSP) | Cada epoch de recompensas (~3,5 días) | ~87.5 days |
| FlareDrop | Concluido | — |
El principal del stake en P-Chain se devuelve al desbloquear y no es un stream de recompensas, aunque aparezca en los saldos de la cuenta.
Estimación de rendimiento
FlareWatch utiliza un modelo de rendimiento de tres niveles. Cada nivel está etiquetado en la interfaz para que el usuario comprenda la precisión de la estimación.
- Nivel 1 — Verdad confirmada. Recompensas reclamables on-chain a través del contrato RewardManager. Este es valor real en la cadena, esperando ser reclamado.
- Nivel 2 — Basado en datos. Cuando el valor reclamable es cero, FlareWatch utiliza la mediana de los últimos cinco reclamos del historial de transacciones de la billetera como estimación para el próximo epoch.
- Nivel 3 — Respaldo de fórmula. Cuando no existe historial de reclamos,
wflrBalance × FTSO_DELEGATION_APR / epochsPerYearproyecta una tasa matemática del estado actual de la red.
FlareWatch muestra un único APY para staking nativo de Flare y delegación FTSO: el pago de la última época de recompensa por FLR después de comisiones, anualizado (× 365 / 3,5 días). No se capitaliza, porque las recompensas de Flare deben reclamarse antes de poder generar más, y coincide con la cifra que publican otros exploradores de Flare. Las posiciones DeFi que se auto-capitalizan (como Sceptre sFLR) muestran su propio APY de protocolo.
Modelo de seguridad — de un vistazo
La seguridad se cubre en detalle en la página Características de seguridad. Los puntos principales son:
- Identidad basada en billetera, no en cuentas. Sin contraseñas, sin identidad vinculada a correo electrónico. La conexión de billetera identifica qué dirección consultar.
- Solo lectura por diseño. La aplicación nunca retiene claves, nunca firma transacciones y nunca interactúa con contratos inteligentes en nombre del usuario.
- Revocación de sesión en el servidor. El cierre de sesión se aplica en el servidor, por lo que una cookie de sesión robada deja de funcionar tan pronto como el usuario cierra sesión, no en su vencimiento de 24 horas.
- Restricción de propiedad por cartera. Cada ruta de API que lee o escribe estado por cartera verifica que la cartera autenticada coincida con la cartera de destino. No hay ninguna ruta de anulación de administrador para datos de usuario.
- Encabezados HTTP en defensa en profundidad. Strict-Transport-Security, una Content-Security-Policy restrictiva, X-Frame-Options DENY y una Permissions-Policy ajustada se incluyen en cada respuesta.
Pruebas
La aplicación se prueba como si cada regresión fuera a ocurrir, porque el tipo de regresiones que FlareWatch considera importantes (cálculos financieros sutilmente incorrectos) son silenciosas cuando se distribuyen. Áreas de cobertura:
- Matemática de APY de staking y delegación FTSO.
- Formato de moneda en múltiples jurisdicciones.
- Formato de cantidad FLR, porcentaje y fecha.
- Lógica de banda de color de umbral (para que una entrega "verde" nunca cambie silenciosamente a ámbar).
- Cálculos de plazos fiscales entre jurisdicciones.
El conjunto de pruebas se ejecuta en CI en cada push.
Infraestructura
FlareWatch se ejecuta en Vercel. El frontend, los trabajos cron que cargan cachés y el almacén de clave-valor respaldado por Redis que contiene esos cachés comparten la plataforma. La elección es deliberada: costo operativo cero a escala, y toda la superficie de implementación es auditable a través de un único proveedor.
La capa services/ es intencionalmente independiente del framework. Si FlareWatch alguna vez se migra fuera de Vercel, los servicios de lógica empresarial son funciones asincrónicas puras y se mueven con él.
Lectura adicional
- Características de Seguridad — autenticación, autorización, limitación de velocidad, encabezados, historial de auditoría.
- Descripción General de Salvaguardas — las reglas arquitectónicas que FlareWatch se impone a sí misma, y por qué.