Aperçu
FlareWatch est une application Next.js qui surveille et suit les positions du réseau Flare — staking, délégation, récompenses et rendement. Le fait architectural déterminant est qu'elle est en lecture seule : il n'y a pas de base de données backend contenant l'état financier de l'utilisateur, aucun chemin de signature de transactions, et aucun accès programmatique aux clés de l'utilisateur. Toutes les données de position proviennent de l'infrastructure on-chain de Flare au moment de la demande.
La connexion au portefeuille (Sign-In-With-Ethereum) existe uniquement pour identifier quelle adresse on-chain interroger. Elle n'autorise pas les actions on-chain car l'application n'a pas d'actions on-chain à autoriser.
Ce que FlareWatch lit, et d'où
Chaque adresse de contrat utilisée par FlareWatch est résolue à l'exécution depuis FlareContractRegistry, le registre d'adresses on-chain canonique de Flare (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). Quand la gouvernance Flare déplace un contrat, FlareWatch utilise la nouvelle adresse à la prochaine session sans changement de code.
Sources de données, par ordre de priorité :
- On-chain (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — source de vérité pour les soldes, les stakes, les récompenses à réclamer, et les prix.
- API Flaremetrics — métadonnées des validateurs et des fournisseurs FTSO trop coûteuses à calculer côté client.
- CoinGecko — données de prix multi-devises et capitalisation boursière.
- Flare Block Explorer — recherches de transactions historiques pour les dossiers fiscaux et la classification des récompenses.
Flux de données en couches
L'application applique une règle de stratification stricte à sens unique :
services → stores → hooks → components → pages
| Couche | Responsabilité |
|---|---|
| Services | Logique métier et récupération de données. Fonctions asynchrones pures. Pas de React. |
| Magasins | État réactif (Zustand). Contiennent les données, pas de récupération. |
| Hooks | Couche de connexion. Appellent les services, écrivent dans les stores. Pas de logique métier. |
| Composants | Lisent depuis les stores via sélecteurs. Affichent l'interface utilisateur. Ne récupèrent jamais. |
| Pages | Composition. Organisent les composants de fonctionnalités. |
En pratique, la récupération, la dérivation et le rendu ont chacun un seul lieu de résidence. Un composant qui a besoin de données de validateurs s'abonne à l'état des validateurs — il n'appelle jamais directement l'API Flaremetrics.
Flux de récompenses
FlareWatch suit quatre flux de récompenses indépendants. Traiter l'un d'eux comme un seul pool provoque un dénombrement significatif des rendements, c'est pourquoi chacun est sourced et calculé séparément.
| Flux | Cadence | Expiration |
|---|---|---|
| Récompenses de délégation FTSO | Chaque époque de récompense (~3,5 jours) | ~87.5 days |
| Gestionnaire de Récompenses de Validation (VRM) | Tous les 4 périodes de récompense (~14 jours) | Jamais |
| Stake en miroir (P-Chain → FSP) | Chaque époque de récompense (~3,5 jours) | ~87.5 days |
| FlareDrop | Terminé | — |
Le capital du stake P-Chain est restitué au déverrouillage et n'est pas un flux de récompenses, même s'il apparaît dans les soldes du compte.
Estimation du rendement
FlareWatch utilise un modèle de rendement à trois niveaux. Chaque niveau est étiqueté dans l'interface utilisateur pour que l'utilisateur comprenne la précision de l'estimation.
- Niveau 1 — Vérité de terrain. Récompenses réclamables on-chain via le contrat RewardManager. C'est une vraie valeur présente on-chain, en attente d'être réclamée.
- Niveau 2 — Basé sur les données. Lorsque la valeur réclamable est zéro, FlareWatch utilise la médiane des cinq derniers sinistres de l'historique des transactions du portefeuille comme estimation pour l'époque suivante.
- Tier 3 — Secours par formule. Quand aucun historique de réclamation n'existe,
wflrBalance × FTSO_DELEGATION_APR / epochsPerYearprojette un taux mathématique à partir de l'état actuel du réseau.
FlareWatch affiche un seul APY pour le staking natif Flare et la délégation FTSO : le paiement par FLR de l'epoch de récompense le plus récent après frais, annualisé (× 365 / 3,5 jours). Il n'est pas composé, car les récompenses Flare doivent être réclamées avant de pouvoir être réinvesties, et cela correspond au chiffre que d'autres explorateurs Flare publient. Les positions DeFi qui composent automatiquement (comme Sceptre sFLR) affichent leur propre APY de protocole.
Modèle de sécurité — en un coup d'œil
La sécurité est couverte en détail sur la page Fonctionnalités de sécurité. Les points clés sont :
- Identité basée sur le portefeuille, non sur les comptes. Pas de mots de passe, pas d'identité liée à un email. La connexion au portefeuille identifie l'adresse à interroger.
- Lecture seule par conception. L'application ne détient jamais de clés, ne signe jamais de transactions et n'interagit jamais avec des contrats intelligents au nom de l'utilisateur.
- Révocation de session côté serveur. La déconnexion est appliquée par le serveur, donc un cookie de session volé cesse de fonctionner dès que l'utilisateur se déconnecte — non à son expiration de 24 heures.
- Contrôle d'accès par portefeuille. Chaque route API qui lit ou écrit un état par portefeuille vérifie que le portefeuille authentifié correspond au portefeuille cible. Il n'y a pas de chemin de dérogation administrateur pour les données utilisateur.
- En-têtes HTTP en profondeur défensive. Strict-Transport-Security, une Content-Security-Policy restrictive, X-Frame-Options DENY, et une Permissions-Policy stricte sont fournis à chaque réponse.
Tests
L'application est testée comme si chaque régression allait se produire — car le type de regressions que FlareWatch considère (les calculs financiers légèrement incorrects) sont silencieux quand ils sont déployés. Domaines de couverture :
- Math d'APY de staking et délégation FTSO.
- Formatage des devises dans plusieurs juridictions.
- Formatage des montants FLR, pourcentages et dates.
- Logique des bandes de couleur de seuil (pour qu'une livraison « verte » ne bascule jamais silencieusement en ambre).
- Calculs des délais fiscaux selon les juridictions.
La suite de tests s'exécute en CI à chaque envoi.
Infrastructure
FlareWatch s'exécute sur Vercel. L'interface, les tâches cron qui préchauffent les caches et le magasin clé-valeur sauvegardé par Redis qui contient ces caches partagent tous la plateforme. Ce choix est délibéré : zéro coût opérationnel à l'échelle, et toute la surface de déploiement est auditable via un seul fournisseur.
La couche services/ est intentionnellement indépendante du framework. Si FlareWatch migrait un jour hors de Vercel, les services de logique métier sont des fonctions async pures et la suivent.
Lectures complémentaires
- Fonctionnalités de sécurité — authentification, autorisation, limitation de débit, en-têtes, historique d'audit.
- Aperçu des mesures de protection — les règles architecturales que FlareWatch s'impose, et pourquoi.