Signaux

Chaque type de watch possède un ou plusieurs signaux. Un signal vérifie une condition, par exemple un commit FTSO manquant ou un solde de crédits sous votre limite. Dans la section 3. Signaux de l’éditeur de watch, vous pouvez activer ou désactiver chaque signal et son avis de rétablissement, et modifier ses paramètres. Rétablir les valeurs par défaut restaure les valeurs standard.

Les signaux appartiennent à des groupes de signaux comme FTSO, FDC ou Soldes. Les groupes comptent pour le routage, car vous pouvez envoyer un groupe à d’autres destinataires que le reste ; voir Destinataires et routage.

Dans la référence ci-dessous, chaque signal répond à quatre questions : ce qui est vérifié, pourquoi c’est important, les causes possibles et ce que vous pouvez faire. Les mêmes textes apparaissent dans l’application lorsque vous cliquez sur l’icône d’information à côté d’un signal.

Presque tous les signaux sont activés par défaut et envoient un avis de rétablissement. Les exceptions sont indiquées dans la référence ci-dessous. Le signal Disponibilité de la surveillance de la Provider Watch est toujours actif et ne peut pas être désactivé, car il vous indique quand la surveillance elle-même n’est pas possible.

Certains signaux fournisseur ont le paramètre Tours consécutifs. Il évite qu’un seul envoi tardif ou manquant vous réveille la nuit. La valeur par défaut est 2.

Exemple avec la valeur par défaut de 2 :

• Tour 1000 : le commit manque. Premier tour consécutif, pas encore d’alerte.
• Tour 1001 : le commit manque de nouveau. Deuxième tour consécutif, alerte.
• Tour 1002 : le commit arrive à temps. Avis de rétablissement, s’il est activé.

Si le tour 1001 avait été correct, rien n’aurait été envoyé. Tant qu’une alerte est active, les tours défaillants suivants ne la renvoient pas ; vous recevez une alerte par incident, pas une par tour. Réglez la valeur sur 1 si vous voulez être informé de chaque manquement.

Un avis de rétablissement vous indique que la situation est revenue à la normale. Il est envoyé aux mêmes destinataires que l’alerte. Si seuls les problèmes vous intéressent, désactivez-le pour chaque signal concerné.

Le cooldown est un réglage propre à chaque watch, appelé Écart minimum entre les alertes. Il supprime les répétitions du même événement pendant ce délai, mais jamais un événement différent comme un avis de rétablissement. Son fonctionnement détaillé est décrit dans Messages et heures calmes.

Lorsque le Watchdog ne peut pas lire une valeur, par exemple parce qu’une source de données est en retard, il ne considère pas cela comme un état sain. Un tour sans preuve interrompt une série de tours défaillants, mais ne déclenche jamais d’avis de rétablissement. Pour la Provider Watch, le signal Disponibilité de la surveillance vous indique quand les données de l’analyseur ont plus de 10 minutes ; tant que c’est le cas, les autres alertes fournisseur de cette watch sont mises en pause plutôt que de reposer sur des suppositions.

1. Ouvrez Vos watches et choisissez Modifier sur la watch.
2. Ouvrez la section 3. Signaux et dépliez le groupe à modifier.
3. Activez ou désactivez le signal ou son avis de rétablissement, ou modifiez un paramètre. Si une valeur est hors plage, la section affiche « Vérifiez les valeurs de cette section. », et l’enregistrement reste bloqué jusqu’à ce que vous la corrigiez.
4. Enregistrez. La modification s’applique dès la vérification suivante.

Événements pour la cible et le seuil choisis.

Variation du solde

Avertit lorsque le solde du wallet configuré dépasse son seuil de variation.

• Que vérifie-t-on ? Compare le solde à l’observation précédente et alerte au seuil dans le sens choisi. La première mesure sert de référence.
• Pourquoi est-ce important ? Un changement de solde peut signaler un transfert entrant ou sortant à suivre.
• Causes possibles : Transferts, frais de gas ou autres changements ont eu lieu entre observations.
• Que faire ? Comparez les montants aux transactions et au jeton configuré.
• Signal activé : activé

Événements pour la cible et le seuil choisis.

Variation du prix

Avertit lorsque le feed configuré dépasse son seuil de variation.

• Que vérifie-t-on ? Compare le prix USD au plus ancien point valide de la fenêtre. Une alerte par fenêtre au seuil ; le double est critique.
• Pourquoi est-ce important ? Un mouvement de prix important peut mériter attention.
• Causes possibles : Le prix actuel diffère du prix valide antérieur dans la fenêtre.
• Que faire ? Comparez les dates et prix, puis la fenêtre et le pourcentage.
• Signal activé : activé

Événements pour la cible et le seuil choisis.

Statut du provider

Avertit lorsque le provider est désinscrit ou perd son éligibilité.

• Que vérifie-t-on ? Après la référence initiale, signale la perte d’inscription ou d’éligibilité et leur retour. Un fournisseur absent des données est considéré non inscrit et non éligible.
• Pourquoi est-ce important ? Un fournisseur non enregistré ou non éligible ne génère aucune récompense pour ses délégateurs pendant cette époque de récompense.
• Causes possibles : L’enregistrement a été manqué ou une condition minimale n’a pas été remplie sans passe restant.
• Que faire ? Vérifiez le fournisseur sur Flare Systems Explorer (conditions minimales et passes) ainsi que son enregistrement pour l’époque actuelle.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Événements pour la cible et le seuil choisis.

Solde de crédits faible

Avertit lorsque votre solde de crédits passe sous le seuil configuré.

• Que vérifie-t-on ? Alerte sous la limite de crédits ; le retour à la limite compte comme rétablissement.
• Pourquoi est-ce important ? Un faible solde de crédits peut affecter les services payants en crédits.
• Causes possibles : Une dépense ou correction peut avoir fait passer le solde sous le seuil.
• Que faire ? Vérifiez le solde et les écritures, puis ajustez le seuil ou rechargez si nécessaire.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Événements pour la cible et le seuil choisis.

Signature des rewards

Avertit des signatures d’uptime et de rewards ouvertes, en retard ou manquées.

• Que vérifie-t-on ? Vérifie les signatures uptime et rewards de l’époque terminée. Alerte après deux heures depuis la fin ou la publication observée ; rappel rewards après douze heures, vote conclu non signé critique.
• Pourquoi est-ce important ? Une signature requise manque ou a raté la clôture du vote.
• Causes possibles : L’identité est absente des signataires observés pour Uptime ou les données de récompense.
• Que faire ? Vérifiez l’époque, l’état du vote et le processus de signature de l’identité.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Participation commit, reveal et signature aux rondes FTSO.

Commit FTSO

Commit absent ou tardif sur plusieurs tours consécutifs.

• Que vérifie-t-on ? Détecte les commits FTSO absents ou tardifs sur des rondes consécutives.
• Pourquoi est-ce important ? Sans commit valide, votre valeur ne compte pas dans ce tour de vote et vous perdez les récompenses liées à sa proximité avec la médiane. Les tours manqués comptent aussi contre la condition minimale des feeds d’ancrage (à moins de 0,5 % de la médiane dans 80 % des tours par époque de récompense).
• Causes possibles : Client FTSO ou Flare System Client arrêté ou en redémarrage, indexeur C-chain en retard sur la chaîne, problèmes RPC ou solde natif insuffisant sur l’adresse d’envoi.
• Que faire ? Vérifiez que le client système affiche « Submitter submit1 successfully sent tx » à chaque tour, que l’indexeur est à jour et que l’adresse d’envoi dispose de fonds.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Tours consécutifs : par défaut 2 (1–20). Nombre de rondes mauvaises consécutives ; 2 ignore un incident isolé. Les données manquantes interrompent la série sans prouver le rétablissement.

Reveal FTSO

Reveal absent, précoce ou tardif sur plusieurs tours consécutifs.

• Que vérifie-t-on ? Détecte les reveals FTSO absents, précoces ou tardifs sur des rondes consécutives.
• Pourquoi est-ce important ? Un commit sans reveal correspondant est pénalisé : votre valeur est exclue et les récompenses du tour sont réduites ou perdues. Un reveal manquant retire aussi votre nombre aléatoire du tour.
• Causes possibles : Le client a redémarré entre commit et reveal, le reveal (submit2) a été envoyé trop tard ou l’adresse d’envoi n’avait plus de fonds.
• Que faire ? Vérifiez les transactions submit2 des tours signalés, les délais entre commit et reveal dans les journaux et un éventuel redémarrage du client entre les deux.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Tours consécutifs : par défaut 2 (1–20). Nombre de rondes mauvaises consécutives ; 2 ignore un incident isolé. Les données manquantes interrompent la série sans prouver le rétablissement.

Signature FTSO

Signature absente ou précoce sur plusieurs tours consécutifs.

• Que vérifie-t-on ? Détecte les signatures FTSO absentes ou précoces ; le délai de grâce a son propre signal.
• Pourquoi est-ce important ? Seules les signatures reçues à temps sur le Merkle root finalisé donnent droit aux récompenses de signature. Une signature manquante fait perdre cette part et ne contribue pas à finaliser le tour.
• Causes possibles : L’étape de signature (submitSignatures) a échoué ou a été retardée, le Merkle root n’a pas pu être calculé ou l’adresse de signature manque de fonds.
• Que faire ? Recherchez « Submitter submitSignatures successfully sent tx » dans les journaux du client système et vérifiez le solde de l’adresse de signature.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Tours consécutifs : par défaut 2 (1–20). Nombre de rondes mauvaises consécutives ; 2 ignore un incident isolé. Les données manquantes interrompent la série sans prouver le rétablissement.

Bitvotes, signatures FDC et accord avec les requêtes de consensus.

Bitvote FDC

Bitvote absent, précoce ou tardif sur plusieurs tours consécutifs.

• Que vérifie-t-on ? Détecte les bitvotes FDC absents, précoces ou tardifs sur des rondes consécutives.
• Pourquoi est-ce important ? Sans bitvote envoyé à temps, vous ne participez pas au consensus FDC du tour. La condition minimale FDC exige une participation réussie dans 60 % des tours de vote par époque de récompense.
• Causes possibles : Client FDC ou vérificateurs indisponibles, source d’attestation (par exemple nœud BTC, DOGE ou XRP) désynchronisée ou bitvote envoyé hors de la phase de choix (90–135 s après le début du tour).
• Que faire ? Vérifiez les journaux du client FDC, le point d’accès /health de chaque vérificateur et si la transaction bitvote arrive pendant la phase de choix.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Tours consécutifs : par défaut 2 (1–20). Nombre de rondes mauvaises consécutives ; 2 ignore un incident isolé. Les données manquantes interrompent la série sans prouver le rétablissement.

Signature FDC

Signature absente ou précoce sur plusieurs tours consécutifs.

• Que vérifie-t-on ? Détecte les signatures FDC absentes ou précoces sur des rondes consécutives.
• Pourquoi est-ce important ? La participation FDC ne compte que si vous soumettez le bon Merkle root. Sans votre signature, le tour ne compte pas pour le seuil de 60 % et vous perdez ses récompenses de signature.
• Causes possibles : Le Merkle root FDC n’a pas pu être construit ou signé, les données des vérificateurs étaient incomplètes ou l’adresse de signature manque de fonds.
• Que faire ? Vérifiez l’état du client FDC et des vérificateurs ainsi que les transactions submitSignatures des tours signalés.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Tours consécutifs : par défaut 2 (1–20). Nombre de rondes mauvaises consécutives ; 2 ignore un incident isolé. Les données manquantes interrompent la série sans prouver le rétablissement.

Submit1 FDC inattendu

Un submit1 FDC a été observé.

• Que vérifie-t-on ? Signale un FDC submit1 observé lorsque les données sont disponibles.
• Pourquoi est-ce important ? Cette phase est inattendue pour FDC et mérite une vérification de configuration.
• Causes possibles : Un submitter peut utiliser le mauvais protocole ou la mauvaise méthode.
• Que faire ? Vérifiez la transaction et la configuration du protocole du submitter.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Requêtes de consensus non confirmées

Tours consécutifs avec des requêtes non confirmées ; une alerte groupée.

• Que vérifie-t-on ? Vérifie les rondes consécutives avec des requêtes de consensus non confirmées et émet une alerte groupée.
• Pourquoi est-ce important ? Les requêtes confirmées par le consensus mais pas par vous signifient généralement que votre vérificateur n’a pas pu les vérifier. Sans ces données, vous ne pouvez souvent pas construire et signer le Merkle root du consensus, et le tour ne compte pas pour vous.
• Causes possibles : Un vérificateur d’une chaîne est arrêté ou en retard, ou sa source de données (par exemple un nœud BTC, DOGE ou XRP) n’est pas synchronisée.
• Que faire ? Identifiez la chaîne ou le type d’attestation des requêtes non confirmées et vérifiez l’état et la synchronisation du vérificateur concerné.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Tours consécutifs : par défaut 2 (1–20). Nombre de rondes mauvaises consécutives ; 2 ignore un incident isolé. Les données manquantes interrompent la série sans prouver le rétablissement.

Longueur du bitvote FDC

La longueur diffère du nombre vérifié de requêtes uniques.

• Que vérifie-t-on ? Compare la longueur du bitvote FDC au nombre de requêtes uniques vérifiées.
• Pourquoi est-ce important ? Un bitvote de longueur incorrecte ne peut pas être associé aux requêtes du tour et ne compte donc ni pour le consensus ni pour votre participation FDC.
• Causes possibles : Le client FDC a vu un ensemble de requêtes différent de celui de la chaîne, par exemple à cause d’un retard de l’indexeur ou d’un problème de version du client après une mise à niveau.
• Que faire ? Vérifiez que l’indexeur C-chain est à jour et que le client FDC utilise la version actuelle, puis comparez le nombre de requêtes dans les journaux.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Indices de reveals incohérents, mauvais signataires ou délais de grâce manqués.

Infraction de reveal

Commit et reveal incohérents ; alerte critique immédiate.

• Que vérifie-t-on ? Une incohérence vérifiée entre commit et reveal FTSO déclenche une alerte critique immédiate.
• Pourquoi est-ce important ? Un reveal qui ne correspond pas à son commit est pénalisé : les récompenses du tour sont réduites ou perdues, et les pénalités peuvent rendre négatif le montant des récompenses à réclamer pour une époque.
• Causes possibles : Le commit et le reveal ont été construits à partir de données différentes, généralement après un redémarrage, ou deux instances actives envoient avec les mêmes adresses.
• Que faire ? Assurez-vous qu’un seul client envoie pour vos adresses et vérifiez les journaux autour du tour signalé.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Signataire incorrect

La signature ne correspond pas à l’adresse de signing policy.

• Que vérifie-t-on ? Vérifie si le signataire FTSO ou FDC diffère de l’adresse de la signing policy.
• Pourquoi est-ce important ? Une signature issue de la mauvaise clé ne compte pas pour votre poids. Vous perdez les récompenses de signature et elle ne contribue pas à finaliser le tour.
• Causes possibles : Le client signe avec une clé qui ne correspond pas à l’adresse de signing policy enregistrée pour votre entité, par exemple après un changement de clé ou une erreur de configuration.
• Que faire ? Comparez le signataire de la transaction signalée à l’adresse de signing policy enregistrée pour votre identité et corrigez la clé de signature configurée.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Délai de signature dépassé

La signature a dépassé le délai donnant droit aux récompenses.

• Que vérifie-t-on ? Vérifie si une signature FTSO ou FDC a dépassé le délai de grâce des récompenses.
• Pourquoi est-ce important ? Les signatures reçues dans les 10 secondes de grâce suivant le début de la signature sont toujours récompensées. Les suivantes ne comptent que si elles arrivent avant la finalisation, qui intervient généralement vite.
• Causes possibles : RPC ou indexeur lent, hôte surchargé ou transactions en attente sur l’adresse de signature.
• Que faire ? Comparez le début de la signature et votre transaction de signature dans les journaux, puis vérifiez les temps de réponse RPC et la charge de l’hôte.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Infraction de révélation FDC

Le bitvote couvre le consensus mais une signature valide manque.

• Que vérifie-t-on ? Signale l’offence FDC : le bitvote couvre le consensus, mais la signature valide manque.
• Pourquoi est-ce important ? Lorsque votre bitvote couvre le consensus, vous devez signer le Merkle root qui en résulte. L’analyseur traite l’absence de signature valide comme une infraction FDC, et les pénalités peuvent réduire vos récompenses de l’époque.
• Causes possibles : L’étape de signature FDC a échoué après le bitvote, souvent parce que des réponses de vérificateurs manquaient et que l’arbre de Merkle n’a pas pu être construit.
• Que faire ? Vérifiez l’état du client FDC et des vérificateurs pour le tour signalé ainsi que la transaction submitSignatures.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Transactions échouées dans les phases surveillées.

Transaction échouée

Une phase de soumission a échoué.

• Que vérifie-t-on ? Signale une transaction échouée dans l’une des cinq phases surveillées.
• Pourquoi est-ce important ? Un envoi annulé coûte du gas et ses données ne sont pas enregistrées ; cette phase compte donc comme manquée pour le tour.
• Causes possibles : Conflits de nonce entre deux clients utilisant la même adresse, gas insuffisant, adresse d’envoi non enregistrée pour l’époque actuelle ou annulation par le contrat après une mise à niveau du protocole.
• Que faire ? Ouvrez la transaction signalée dans l’explorateur, lisez le motif d’annulation et assurez-vous qu’un seul client utilise chaque adresse d’envoi.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Activité Fast Updates selon le poids de signature et les blocs écoulés.

Inactivité Fast Updates

Alerte en cas d’inactivité statistiquement improbable. Avertissements par nombre de blocs désactivés par défaut.

• Que vérifie-t-on ? Compare la probabilité modélisée sans Fast Updates au seuil selon le poids et les blocs écoulés. L’alerte optionnelle utilise 1 % des blocs de l’époque.
• Pourquoi est-ce important ? Fast Updates (feeds à latence de bloc) fait partie des conditions minimales : vous devez soumettre au moins 80 % des mises à jour attendues par époque de récompense, sauf si votre poids est inférieur à 0,2 % du total.
• Causes possibles : Le client Fast Updates s’est arrêté, ses comptes n’ont plus de fonds pour le gas (« insufficient funds ») ou la clé de tirage au sort n’est pas enregistrée.
• Que faire ? Vérifiez les journaux du client Fast Updates et les soldes de tous ses comptes. Avec un faible poids, de longs intervalles entre les sélections sont normaux.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Seuil de probabilité : par défaut 1E-7 (1E-15–0,1). Un seuil plus petit exige davantage d’indices statistiques d’inactivité Fast Updates.
• Activer l’avertissement par blocs : par défaut désactivé. Alerte aussi à 1 % des blocs d’époque sans mise à jour ; désactivé par défaut.

Inscription à la prochaine époque et présence dans la signing policy active.

Inscription à la prochaine époque

Une seule alerte si l’inscription reste en attente après le délai choisi.

• Que vérifie-t-on ? Vérifie si l’inscription à la prochaine époque manque après le délai depuis son ouverture.
• Pourquoi est-ce important ? Manquer l’enregistrement pour une époque de récompense signifie aucune participation ni récompense FSP pendant toute cette époque, et vos passes sont remis à zéro.
• Causes possibles : Le client système ne fonctionnait pas pendant la fenêtre d’enregistrement de 30 minutes, la transaction d’enregistrement a échoué ou une adresse de l’entité manquait de fonds.
• Que faire ? Recherchez « Voter … registered for epoch … » dans les journaux du client système et assurez-vous qu’il fonctionne pendant la fenêtre d’enregistrement ; l’enregistrement n’est possible qu’à ce moment-là.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Délai en minutes : par défaut 15 (1–1 440). Attend ce nombre de minutes après l’ouverture avant d’alerter sur l’inscription absente.

Appartenance à la signing policy

L’identité ne figure pas dans la signing policy active.

• Que vérifie-t-on ? Vérifie si l’identité manque dans la signing policy active.
• Pourquoi est-ce important ? Seules les entités de la signing policy active peuvent soumettre, signer et recevoir des récompenses pendant l’époque de récompense actuelle.
• Causes possibles : L’enregistrement pour cette époque a été manqué ou n’a pas abouti.
• Que faire ? Il n’est plus possible de rejoindre l’époque actuelle. Assurez-vous que le prochain enregistrement réussit et vérifiez les journaux de la dernière fenêtre d’enregistrement.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Fonds natifs des adresses opérationnelles utilisées pour les transactions.

Solde opérationnel faible

Vérification horaire du solde natif des adresses submit, signatures et signing policy.

• Que vérifie-t-on ? Compare les soldes natifs en cache aux seuils ; une erreur de lecture ne prouve pas le rétablissement.
• Pourquoi est-ce important ? Un faible solde natif peut empêcher le paiement du gas.
• Causes possibles : Le gas ou des transferts sortants ont pu réduire le solde.
• Que faire ? Identifiez l’adresse et ses transactions avant de la réapprovisionner.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Avertissement sous (FLR/SGB) : par défaut 25 (0,001–1 000 000). Alerte si un solde natif lisible est strictement inférieur à ce montant.
• Critique sous (FLR/SGB) : par défaut 5 (0–1 000 000). Passe l’alerte de solde en critique sous ce montant, qui ne doit pas dépasser le seuil d’avertissement.

Disponibilité et fraîcheur des données de surveillance.

Disponibilité de la surveillance

Toujours actif. Suspend les alertes du fournisseur si l’analyseur ou ses résultats sont obsolètes.

• Que vérifie-t-on ? Vérifie toujours l’analyseur. Des données absentes, en erreur ou âgées de plus de dix minutes suspendent l’évaluation.
• Pourquoi est-ce important ? Un suivi périmé ne permet pas d’évaluer le fournisseur.
• Causes possibles : L’analyseur peut être arrêté, en échec ou privé de rondes complètes.
• Que faire ? Vérifiez le statut, la dernière exécution et la fraîcheur des rondes indexées.
• Signal activé : Toujours actif
• Envoyer un avis de rétablissement : activé

Alertes observées FTSO et FDC, distinctes des décisions officielles Minimal Conditions.

Alerte précoce Anchor

Taux observé sous le seuil de la fenêtre ; aucune décision officielle d’éligibilité.

• Que vérifie-t-on ? Vérifie le taux observé des feeds d’ancrage FTSO avec assez d’échantillons récents. Non applicable sans poids de signature.
• Pourquoi est-ce important ? Officiellement, les estimations des feeds d’ancrage doivent se situer à moins de 0,5 % de la médiane dans 80 % des tours de vote par époque de récompense. Cette fenêtre est un indicateur précoce, pas le résultat officiel.
• Causes possibles : Une faible participation, des coupures ou des observations incomplètes peuvent réduire la valeur.
• Que faire ? Vérifiez la fenêtre, le nombre d’observations et la fraîcheur des données avant d’examiner le fournisseur ou validateur.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Alerte sous (%) : par défaut 80 % (1 %–100 %). Alerte sous ce pourcentage avec assez d’observations récentes ; rétablissement deux points au-dessus, au maximum 100 %.
• Fenêtre : par défaut 2 heures. Fenêtre d’observation en heures, pas une évaluation de toute l’époque.
• Observations minimales : par défaut 40 (10–240). Nombre minimal d’observations avant d’évaluer le pourcentage.

Alerte précoce FDC

Participation FDC sous le seuil. Les tours sans consensus sont exclus.

• Que vérifie-t-on ? Vérifie la participation FDC aux rondes de consensus ; exclut les rondes sans consensus et le poids nul.
• Pourquoi est-ce important ? Officiellement, FDC exige une participation réussie (le bon Merkle root) dans 60 % des tours de vote par époque de récompense. Votre seuil ici peut avertir plus tôt.
• Causes possibles : Une faible participation, des coupures ou des observations incomplètes peuvent réduire la valeur.
• Que faire ? Vérifiez la fenêtre, le nombre d’observations et la fraîcheur des données avant d’examiner le fournisseur ou validateur.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Alerte sous (%) : par défaut 80 % (1 %–100 %). Alerte sous ce pourcentage avec assez d’observations récentes ; rétablissement deux points au-dessus, au maximum 100 %.
• Fenêtre : par défaut 2 heures. Fenêtre d’observation en heures, pas une évaluation de toute l’époque.
• Observations minimales : par défaut 40 (10–240). Nombre minimal d’observations avant d’évaluer le pourcentage.

Connectivité P-chain observée et présence des NodeIDs enregistrés parmi les validateurs.

Connectivité du validateur

Plusieurs vues P-chain ; alerte désactivée en attendant la vérification parallèle.

• Que vérifie-t-on ? Vérifie la connectivité observée depuis plusieurs vues P-chain, pas l’Uptime officielle. Désactivé par défaut.
• Pourquoi est-ce important ? Le staking exige 80 % de disponibilité totale par époque de récompense. Il s’agit d’un signal de connectivité observée, pas de la disponibilité officielle.
• Causes possibles : Une faible participation, des coupures ou des observations incomplètes peuvent réduire la valeur.
• Que faire ? Vérifiez la fenêtre, le nombre d’observations et la fraîcheur des données avant d’examiner le fournisseur ou validateur.
• Signal activé : désactivé
• Envoyer un avis de rétablissement : activé
• Alerte sous (%) : par défaut 80 % (1 %–100 %). Alerte sous ce pourcentage avec assez d’observations récentes ; rétablissement deux points au-dessus, au maximum 100 %.
• Fenêtre : par défaut 2 heures. Fenêtre d’observation en heures, pas une évaluation de toute l’époque.
• Observations minimales : par défaut 40 (10–240). Nombre minimal d’observations avant d’évaluer le pourcentage.

Validateur non répertorié

Aucun NodeID enregistré n’est un validateur actuel. Vérifiez si le stake manque ou a expiré. Sans NodeID : non applicable.

• Que vérifie-t-on ? Alerte si tous les NodeIDs enregistrés sont confirmés absents ; sans NodeID ou avec un résultat inconnu, aucune absence n’est conclue.
• Pourquoi est-ce important ? Un nœud qui n’est pas validateur actif ne reçoit aucune récompense de staking, et la condition minimale de staking exige 80 % de disponibilité totale par époque de récompense.
• Causes possibles : La période de staking du validateur a pris fin, le nœud n’a jamais été ajouté comme validateur ou le NodeID lié à l’entité a changé.
• Que faire ? Vérifiez la date de fin du staking du nœud, renouvelez-le si nécessaire et confirmez le NodeID lié à votre identité.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé

Récompenses personnelles non réclamées des adresses du fournisseur, par époque.

Récompenses personnelles non réclamées

Un récapitulatif par époque des récompenses DIRECT/FEE réclamables, vérifiées avec preuves. Les réserves des délégateurs sont exclues.

• Que vérifie-t-on ? Signale une fois par époque les récompenses personnelles directes et de frais au-dessus du minimum ; rétablissement à ce seuil ou en dessous.
• Pourquoi est-ce important ? Les récompenses FSP expirent après 25 époques de récompense (environ trois mois) ; les récompenses directes et de frais non réclamées sont alors perdues.
• Causes possibles : Les récompenses sont disponibles ou le claim n’apparaît pas encore dans le cache.
• Que faire ? Vérifiez l’époque, le montant et le statut du claim.
• Signal activé : activé
• Envoyer un avis de rétablissement : activé
• Montant minimal (FLR/SGB) : par défaut 1 (0–1 000 000 000). Alerte seulement si les récompenses personnelles dépassent strictement ce montant natif.