Signale

Jeder Watch-Typ hat ein oder mehrere Signale. Ein Signal prüft eine Bedingung, zum Beispiel einen fehlenden FTSO-Commit oder ein Credit-Guthaben unter deiner Grenze. Im Abschnitt 3. Signale des Watch-Editors kannst du jedes Signal ein- und ausschalten, seine Erholungsmeldung schalten und seine Parameter ändern. Auf Standard zurücksetzen stellt die Standardwerte wieder her.

Signale gehören zu Signalgruppen wie FTSO, FDC oder Guthaben. Gruppen sind für das Routing wichtig, denn du kannst eine Gruppe an andere Empfänger schicken als den Rest; siehe Empfänger und Routing.

Jedes Signal in der Referenz unten beantwortet vier Fragen: was geprüft wird, warum das wichtig ist, typische Ursachen und was du tun kannst. Dieselben Texte erscheinen in der App, wenn du auf das Info-Symbol neben einem Signal klickst.

Fast jedes Signal ist standardmäßig aktiv und schickt eine Erholungsmeldung. Die Ausnahmen sind in der Referenz unten markiert. Das Signal Verfügbarkeit der Überwachung der Provider-Watch ist immer aktiv und lässt sich nicht ausschalten, weil es dir sagt, wann die Überwachung selbst nicht möglich ist.

Manche Provider-Signale haben den Parameter Runden in Folge. Er verhindert, dass dich eine einzelne verspätete oder fehlende Einreichung nachts weckt. Der Standard ist 2.

Beispiel mit dem Standard 2:

• Runde 1000: Der Commit fehlt. Erste Runde in Folge, noch kein Alarm.
• Runde 1001: Der Commit fehlt wieder. Zweite Runde in Folge, Alarm.
• Runde 1002: Der Commit kommt pünktlich. Erholungsmeldung, wenn sie eingeschaltet ist.

Wäre Runde 1001 in Ordnung gewesen, wäre gar nichts verschickt worden. Solange ein Alarm aktiv ist, lösen weitere schlechte Runden ihn nicht erneut aus; du bekommst einen Alarm pro Vorfall, nicht einen pro Runde. Stell den Wert auf 1, wenn du von jedem einzelnen Aussetzer erfahren willst.

Eine Erholungsmeldung sagt dir, dass der Zustand wieder normal ist. Sie geht an dieselben Empfänger wie der Alarm. Wenn dich nur Probleme interessieren, schalte sie je Signal aus.

Der Cooldown ist eine Einstellung je Watch und heißt Mindestabstand zwischen Alarmen. Er unterdrückt Wiederholungen desselben Ereignisses innerhalb dieser Zeit, aber nie ein anderes Ereignis wie eine Erholungsmeldung. Die Einzelheiten stehen unter Nachrichten und Ruhezeiten.

Kann der Watchdog einen Wert nicht lesen, etwa weil eine Datenquelle verspätet ist, wertet er das nicht als gesund. Eine Runde ohne Nachweis unterbricht eine Serie schlechter Runden, löst aber nie eine Erholungsmeldung aus. Bei der Provider-Watch sagt dir das Signal Verfügbarkeit der Überwachung, wenn die Analyzer-Daten älter als 10 Minuten sind; solange das so ist, pausieren die anderen Provider-Alarme dieser Watch, statt zu raten.

1. Öffne Deine Watches und wähle bei der Watch Bearbeiten.
2. Öffne den Abschnitt 3. Signale und klappe die Gruppe auf, die du ändern willst.
3. Schalte das Signal oder seine Erholungsmeldung um, oder ändere einen Parameter. Liegt ein Wert außerhalb des erlaubten Bereichs, zeigt der Abschnitt den Hinweis „Bitte die Werte in diesem Abschnitt prüfen.“, und Speichern bleibt gesperrt, bis du ihn korrigierst.
4. Speichere. Die Änderung gilt ab der nächsten Prüfung.

Ereignisse zum gewählten Watch-Ziel und seiner Schwelle.

Guthabenänderung

Benachrichtigt, wenn sich das konfigurierte Wallet-Guthaben über den Schwellenwert hinaus ändert.

• Was wird geprüft? Vergleicht das Guthaben mit der vorherigen Beobachtung und meldet Änderungen ab der Schwelle in der gewählten Richtung. Die erste Beobachtung setzt den Ausgangswert.
• Warum ist das wichtig? Eine Guthabenänderung kann auf einen Eingang oder Ausgang hinweisen, den du beobachten möchtest.
• Typische Ursachen: Zwischen den Beobachtungen gab es Transfers, Gasgebühren oder andere Guthabenänderungen.
• Was tun? Beobachtete Beträge mit letzten Wallet-Transaktionen und dem konfigurierten Token abgleichen.
• Signal aktiviert: an

Ereignisse zum gewählten Watch-Ziel und seiner Schwelle.

Preisbewegung

Benachrichtigt, wenn sich der konfigurierte Feed über den Schwellenwert hinaus bewegt.

• Was wird geprüft? Vergleicht den USD-Feedpreis mit dem ältesten gültigen Punkt im Fenster. Alarm ab der Prozentschwelle, höchstens einmal je Fenster; doppelte Schwelle ist kritisch.
• Warum ist das wichtig? Eine große beobachtete Preisbewegung kann Aufmerksamkeit erfordern.
• Typische Ursachen: Der aktuelle Feed-Preis weicht vom früheren gültigen Preis im gewählten Fenster ab.
• Was tun? Zeitpunkte und Preise vergleichen sowie Fenster und Prozentsatz prüfen.
• Signal aktiviert: an

Ereignisse zum gewählten Watch-Ziel und seiner Schwelle.

Provider-Status

Benachrichtigt, wenn der Provider abgemeldet wird oder seine Eligibility verliert.

• Was wird geprüft? Meldet nach der ersten Beobachtung den Verlust von Registrierung oder Eligibility sowie deren Erholung. Ein Provider ohne Datensatz gilt als unregistriert und nicht berechtigt.
• Warum ist das wichtig? Ein nicht registrierter oder nicht berechtigter Provider verdient in dieser Reward-Epoche keine Rewards für seine Delegatoren.
• Typische Ursachen: Die Registrierung wurde verpasst, oder eine Minimal Condition wurde ohne verbleibenden Pass verfehlt.
• Was tun? Prüfe den Provider im Flare Systems Explorer (Minimal Conditions und Passes) und seine Registrierung für die laufende Epoche.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Ereignisse zum gewählten Watch-Ziel und seiner Schwelle.

Niedriges Credits-Guthaben

Benachrichtigt, wenn dein Credits-Guthaben unter den konfigurierten Schwellenwert fällt.

• Was wird geprüft? Alarmiert, wenn das Credit-Guthaben der Wallet strikt unter die Grenze fällt; bei Erholung zählt auch Gleichheit mit der Grenze.
• Warum ist das wichtig? Niedriges Credit-Guthaben kann Dienste beeinträchtigen, die Credits verbrauchen.
• Typische Ursachen: Credit-Verbrauch oder eine Korrektur kann das Guthaben unter deine Schwelle gebracht haben.
• Was tun? Credit-Guthaben und letzte Buchungen prüfen, dann bei Bedarf Schwelle anpassen oder auffüllen.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Ereignisse zum gewählten Watch-Ziel und seiner Schwelle.

Reward-Signierung

Benachrichtigt über offene, überfällige oder verpasste Uptime- und Reward-Signaturen.

• Was wird geprüft? Prüft fehlende Uptime- und Reward-Signaturen der gerade beendeten Epoche. Offene Alarme warten zwei Stunden ab Epochenende bzw. erstmals beobachteter Datenveröffentlichung; nach zwölf Stunden folgt die Reward-Erinnerung, eine abgeschlossene unsignierte Abstimmung ist kritisch.
• Warum ist das wichtig? Eine nötige Provider-Signatur steht aus oder wurde vor Abschluss der Abstimmung verpasst.
• Typische Ursachen: Die Identity fehlt in der beobachteten Unterzeichnerliste für Uptime oder Reward-Daten.
• Was tun? Epoche, Abstimmungsstatus und Signierprozess der konfigurierten Identity prüfen.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Commit-, Reveal- und Signaturteilnahme an FTSO-Voting-Runden.

FTSO-Commit

Commit fehlt oder ist in aufeinanderfolgenden Runden verspätet.

• Was wird geprüft? Prüft fehlende oder verspätete FTSO-Commits in aufeinanderfolgenden Voting-Runden.
• Warum ist das wichtig? Ohne gültigen Commit zählt dein Wert in dieser Voting-Runde nicht, die Median-Rewards der Runde entfallen. Verpasste Runden zählen außerdem gegen die Minimal Condition der Anker-Feeds (in 80 % der Runden je Reward-Epoche innerhalb 0,5 % vom Median).
• Typische Ursachen: FTSO-Client oder Flare System Client gestoppt bzw. im Neustart, der C-Chain-Indexer hinkt hinterher, RPC-Probleme oder zu wenig Guthaben auf der Submit-Adresse.
• Was tun? Prüfe, ob der System Client jede Runde „Submitter submit1 successfully sent tx“ meldet, ob der Indexer auf aktuellem Stand ist und ob die Submit-Adresse Guthaben hat.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Runden in Folge: Standard 2 (1–20). Zahl aufeinanderfolgender schlechter Voting-Runden; 2 ignoriert einen einzelnen Aussetzer. Fehlende Belege setzen die Serie zurück, belegen aber keine Erholung.

FTSO-Reveal

Reveal fehlt, ist zu früh oder verspätet.

• Was wird geprüft? Prüft fehlende, zu frühe oder verspätete FTSO-Reveals in aufeinanderfolgenden Voting-Runden.
• Warum ist das wichtig? Ein Commit ohne passenden Reveal wird bestraft: Dein Wert fällt heraus, die Rewards der Runde werden gekürzt oder entfallen. Ein fehlender Reveal nimmt außerdem deine Zufallszahl aus der Runde.
• Typische Ursachen: Der Client wurde zwischen Commit und Reveal neu gestartet, der Reveal (submit2) ging zu spät raus, oder die Submit-Adresse hatte kein Guthaben mehr.
• Was tun? Prüfe die submit2-Transaktionen der gemeldeten Runden, den zeitlichen Abstand zwischen Commit und Reveal im Log und ob der Client dazwischen neu gestartet wurde.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Runden in Folge: Standard 2 (1–20). Zahl aufeinanderfolgender schlechter Voting-Runden; 2 ignoriert einen einzelnen Aussetzer. Fehlende Belege setzen die Serie zurück, belegen aber keine Erholung.

FTSO-Signatur

Signatur fehlt oder ist in aufeinanderfolgenden Runden zu früh.

• Was wird geprüft? Prüft fehlende oder zu frühe FTSO-Signaturen in aufeinanderfolgenden Voting-Runden; verpasste Grace-Zeiten sind ein eigenes Signal.
• Warum ist das wichtig? Signatur-Rewards gibt es nur für rechtzeitige Signaturen auf den finalisierten Merkle-Root. Eine fehlende Signatur kostet diesen Anteil und hilft nicht beim Finalisieren der Runde.
• Typische Ursachen: Der Signierschritt (submitSignatures) ist fehlgeschlagen oder kam zu spät, der Merkle-Root konnte nicht berechnet werden, oder der Submit-Signatures-Adresse fehlt Guthaben.
• Was tun? Suche im Log des System Clients nach „Submitter submitSignatures successfully sent tx“ und prüfe das Guthaben der Submit-Signatures-Adresse.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Runden in Folge: Standard 2 (1–20). Zahl aufeinanderfolgender schlechter Voting-Runden; 2 ignoriert einen einzelnen Aussetzer. Fehlende Belege setzen die Serie zurück, belegen aber keine Erholung.

FDC-Bitvotes, Signaturen und Übereinstimmung mit Konsensanfragen.

FDC-Bitvote

Bitvote fehlt, ist zu früh oder verspätet.

• Was wird geprüft? Prüft fehlende, zu frühe oder verspätete FDC-Bitvotes in aufeinanderfolgenden Voting-Runden.
• Warum ist das wichtig? Ohne rechtzeitigen Bitvote nimmst du am FDC-Konsens dieser Runde nicht teil. Die FDC-Minimal-Condition verlangt erfolgreiche Teilnahme in 60 % der Voting-Runden je Reward-Epoche.
• Typische Ursachen: FDC-Client oder Verifier nicht erreichbar, eine Datenquelle (etwa BTC-, DOGE- oder XRP-Node) nicht synchron, oder der Bitvote wurde außerhalb der Choose-Phase gesendet (90–135 s in der Runde).
• Was tun? Prüfe das Log des FDC-Clients und den /health-Endpunkt jedes Verifiers sowie, ob die Bitvote-Transaktion in der Choose-Phase landet.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Runden in Folge: Standard 2 (1–20). Zahl aufeinanderfolgender schlechter Voting-Runden; 2 ignoriert einen einzelnen Aussetzer. Fehlende Belege setzen die Serie zurück, belegen aber keine Erholung.

FDC-Signatur

Signatur fehlt oder ist in aufeinanderfolgenden Runden zu früh.

• Was wird geprüft? Prüft fehlende oder zu frühe FDC-Signaturen in aufeinanderfolgenden Voting-Runden.
• Warum ist das wichtig? FDC-Teilnahme zählt nur, wenn du den richtigen Merkle-Root signierst. Ohne deine Signatur zählt die Runde nicht für die 60-Prozent-Bedingung, und die Signatur-Rewards entfallen.
• Typische Ursachen: Der FDC-Merkle-Root konnte nicht gebaut oder signiert werden, Verifier-Daten waren unvollständig, oder der Submit-Signatures-Adresse fehlt Guthaben.
• Was tun? Prüfe FDC-Client, Verifier-Gesundheit und die submitSignatures-Transaktionen der gemeldeten Runden.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Runden in Folge: Standard 2 (1–20). Zahl aufeinanderfolgender schlechter Voting-Runden; 2 ignoriert einen einzelnen Aussetzer. Fehlende Belege setzen die Serie zurück, belegen aber keine Erholung.

Unerwartetes FDC-Submit1

Ein FDC-Submit1 wurde beobachtet.

• Was wird geprüft? Meldet ein beobachtetes FDC-submit1, wenn Einreichungsdaten verfügbar sind.
• Warum ist das wichtig? Diese Einreichungsphase ist für FDC unerwartet und sollte auf Fehlkonfiguration geprüft werden.
• Typische Ursachen: Ein Submitter kann das falsche Protokoll oder die falsche Einreichungsmethode nutzen.
• Was tun? Gemeldete Transaktion und Protokollkonfiguration des Submitters prüfen.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Unbestätigte Konsens-Requests

Aufeinanderfolgende Runden mit unbestätigten Konsens-Requests; eine Sammelmeldung.

• Was wird geprüft? Prüft aufeinanderfolgende Voting-Runden mit mindestens einer unbestätigten Konsensanfrage und meldet sie gebündelt.
• Warum ist das wichtig? Anfragen, die der Konsens bestätigt hat, du aber nicht, heißen meist: Dein Verifier konnte sie nicht prüfen. Ohne diese Daten kannst du den Konsens-Merkle-Root oft nicht bauen und signieren, und die Runde zählt für dich nicht.
• Typische Ursachen: Ein Verifier für eine Chain ist ausgefallen oder hängt hinterher, oder seine Datenquelle (etwa ein BTC-, DOGE- oder XRP-Node) ist nicht synchron.
• Was tun? Finde heraus, zu welcher Chain bzw. welchem Attestation-Typ die unbestätigten Anfragen gehören, und prüfe Gesundheit und Sync-Stand dieses Verifiers.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Runden in Folge: Standard 2 (1–20). Zahl aufeinanderfolgender schlechter Voting-Runden; 2 ignoriert einen einzelnen Aussetzer. Fehlende Belege setzen die Serie zurück, belegen aber keine Erholung.

FDC-Bitvote-Länge

Bitvote-Länge weicht von der geprüften Zahl eindeutiger Requests ab.

• Was wird geprüft? Prüft, ob die FDC-Bitvote-Länge zur Zahl verifizierter eindeutiger Anfragen passt.
• Warum ist das wichtig? Ein Bitvote mit falscher Länge lässt sich den Anfragen der Runde nicht zuordnen und zählt weder für den Konsens noch für deine FDC-Teilnahme.
• Typische Ursachen: Der FDC-Client hat andere Anfragen gesehen als die Chain, etwa wegen Verzögerung im Indexer oder eines Versionsproblems nach einem Update.
• Was tun? Prüfe, ob der C-Chain-Indexer aktuell ist und der FDC-Client die aktuelle Version hat, und vergleiche dann die Zahl der Anfragen im Log.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Nachweise für Reveal-Widersprüche, falsche Signierer oder verpasste Signatur-Grace-Zeiten.

Reveal-Verstoß

Commit und Reveal passen nicht zusammen; sofortiger kritischer Alarm.

• Was wird geprüft? Ein nachgewiesener Widerspruch zwischen FTSO-Commit und Reveal löst sofort einen kritischen Alarm aus.
• Warum ist das wichtig? Ein Reveal, der nicht zum Commit passt, wird bestraft: Die Rewards der Runde werden gekürzt oder entfallen, und Strafen können die Reward-Claims einer Epoche ins Negative drücken.
• Typische Ursachen: Commit und Reveal entstanden aus unterschiedlichen Daten, typisch nach einem Neustart, oder zwei laufende Instanzen senden mit denselben Adressen.
• Was tun? Stelle sicher, dass genau ein Client für deine Adressen sendet, und prüfe das Log rund um die gemeldete Runde.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Falscher Signierer

Signatur passt nicht zur Signing-Policy-Adresse.

• Was wird geprüft? Prüft, ob eine FTSO- oder FDC-Signatur von der Signing-Policy-Adresse abweicht.
• Warum ist das wichtig? Eine Signatur mit dem falschen Schlüssel zählt nicht für dein Gewicht. Du verlierst die Signatur-Rewards, und sie hilft nicht beim Finalisieren.
• Typische Ursachen: Der Client signiert mit einem Schlüssel, der nicht die registrierte Signing-Policy-Adresse deiner Entity ist, etwa nach einem Schlüsselwechsel oder bei einem falschen Schlüssel in der Konfiguration.
• Was tun? Vergleiche den Unterzeichner der gemeldeten Transaktion mit der für deine Identity registrierten Signing-Policy-Adresse und korrigiere den konfigurierten Signierschlüssel.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Signaturfrist verpasst

Signatur hat die Belohnungsfrist verpasst.

• Was wird geprüft? Prüft, ob eine FTSO- oder FDC-Signatur ihre Reward-Grace-Zeit verpasst hat.
• Warum ist das wichtig? Signaturen in den ersten 10 Sekunden nach Signierbeginn werden immer belohnt. Spätere zählen nur, wenn sie noch vor der Finalisierung ankommen, und die folgt meist schnell.
• Typische Ursachen: Langsamer RPC oder Indexer, ein ausgelasteter Host oder eine Warteschlange von Transaktionen auf der Submit-Signatures-Adresse.
• Was tun? Vergleiche im Log den Signierbeginn mit deiner Signatur-Transaktion und prüfe RPC-Antwortzeiten und Auslastung des Hosts.
• Signal aktiviert: an
• Erholungsmeldung senden: an

FDC-Reveal-Verstoß

Der Bitvote deckt den Konsens ab, aber eine gültige Signatur fehlt.

• Was wird geprüft? Meldet die FDC-Reveal-Offence des Analyzers: Der Bitvote deckt den Konsens ab, aber eine gültige Signatur fehlt.
• Warum ist das wichtig? Deckt dein Bitvote den Konsens, wird von dir die Signatur des daraus entstehenden Merkle-Roots erwartet. Der Analyzer wertet eine fehlende gültige Signatur als FDC-Verstoß, und Strafen können deine Epochen-Rewards mindern.
• Typische Ursachen: Der FDC-Signierschritt ist nach dem Bitvote gescheitert, oft weil Verifier-Antworten fehlten und der Merkle-Baum nicht gebaut werden konnte.
• Was tun? Prüfe FDC-Client und Verifier-Gesundheit für die gemeldete Runde sowie die submitSignatures-Transaktion.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Fehlgeschlagene Transaktionen der überwachten Einreichungsphasen.

Fehlgeschlagene Transaktion

Eine Abgabephase ist fehlgeschlagen.

• Was wird geprüft? Meldet eine fehlgeschlagene Transaktion in einer der fünf überwachten Einreichungsphasen.
• Warum ist das wichtig? Eine fehlgeschlagene Submission kostet Gas, ihre Daten werden nicht erfasst, und die Phase gilt für diese Runde als verpasst.
• Typische Ursachen: Nonce-Konflikte durch zwei Clients auf derselben Adresse, zu wenig Gas, eine für die laufende Epoche nicht registrierte Absenderadresse oder ein Contract-Revert nach einem Protokoll-Update.
• Was tun? Öffne die gemeldete Transaktion im Explorer, lies den Revert-Grund und stelle sicher, dass jede Submit-Adresse nur von einem Client genutzt wird.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Fast-Updates-Aktivität im Verhältnis zu Signing-Gewicht und vergangenen Blöcken.

Fast-Updates-Inaktivität

Alarm bei statistisch unwahrscheinlicher Inaktivität. Blockzahl-Warnungen sind standardmäßig aus.

• Was wird geprüft? Vergleicht die modellierte Wahrscheinlichkeit ohne Fast Updates anhand von Signing-Gewicht und vergangenen Blöcken mit der Schwelle. Die optionale Blockwarnung nutzt 1 % der Blöcke einer Reward-Epoche.
• Warum ist das wichtig? Fast Updates (Block-Latenz-Feeds) gehören zu den Minimal Conditions: Du musst mindestens 80 % deiner erwarteten Updates je Reward-Epoche liefern, außer dein Gewicht liegt unter 0,2 % des Gesamtgewichts.
• Typische Ursachen: Der Fast-Updates-Client ist gestoppt, seinen Konten fehlt Gas-Guthaben („insufficient funds“), oder der Sortition-Key ist nicht registriert.
• Was tun? Prüfe das Log des Fast-Updates-Clients und die Guthaben aller Fast-Updates-Konten. Bei geringem Gewicht sind lange Pausen zwischen zwei Auswahlen normal.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Wahrscheinlichkeitsschwelle: Standard 1E-7 (1E-15–0,1). Eine kleinere Wahrscheinlichkeitsschwelle verlangt stärkere statistische Hinweise auf Fast-Updates-Inaktivität.
• Blockzahl-Warnung aktivieren: Standard aus. Warnt zusätzlich, wenn Blöcke ohne Updates 1 % der Blöcke einer Reward-Epoche erreichen; standardmäßig aus.

Registrierung der nächsten Epoche und Mitgliedschaft in der aktiven Signing Policy.

Registrierung für nächste Epoche

Einmaliger Alarm bei ausstehender Registrierung nach der eingestellten Wartezeit.

• Was wird geprüft? Prüft, ob die Registrierung für die nächste Reward-Epoche nach der eingestellten Wartezeit seit Öffnung noch fehlt.
• Warum ist das wichtig? Wer die Registrierung für eine Reward-Epoche verpasst, nimmt in der ganzen Epoche nicht teil, bekommt keine FSP-Rewards, und die Passes werden auf null gesetzt.
• Typische Ursachen: Der System Client lief im 30-minütigen Registrierungsfenster nicht, die Registrierungs-Transaktion ist fehlgeschlagen, oder einer Adresse der Entity fehlte Guthaben.
• Was tun? Suche im Log des System Clients nach „Voter … registered for epoch …“ und sorge dafür, dass der Client im Registrierungsfenster läuft. Nur dann ist eine Registrierung möglich.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Wartezeit in Minuten: Standard 15 (1–1.440). Wartet so viele Minuten nach Registrierungsöffnung, bevor eine fehlende Registrierung gemeldet wird.

Signing-Policy-Mitgliedschaft

Identity ist nicht in der aktiven Signing Policy.

• Was wird geprüft? Prüft, ob die Identity in der aktiven Signing Policy fehlt.
• Warum ist das wichtig? Nur Entities in der aktiven Signing Policy können in der laufenden Reward-Epoche senden, signieren und Rewards verdienen.
• Typische Ursachen: Die Registrierung für diese Epoche wurde verpasst oder ist nicht durchgegangen.
• Was tun? Der laufenden Epoche kannst du nicht mehr beitreten. Sorge dafür, dass die nächste Registrierung klappt, und prüfe das Log des letzten Registrierungsfensters.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Native Guthaben der für Transaktionen verwendeten Provider-Betriebsadressen.

Niedriges Betriebsguthaben

Stündliche Prüfung des nativen Guthabens der Submit-, Signatures- und Signing-Policy-Adressen.

• Was wird geprüft? Prüft zwischengespeicherte native Guthaben der Betriebsadressen gegen Warn- und kritische Schwellen; ein Lesefehler belegt keine Erholung.
• Warum ist das wichtig? Wenig natives Guthaben kann die Gaszahlung für operative Transaktionen verhindern.
• Typische Ursachen: Gasverbrauch oder ausgehende Transfers können das Guthaben einer operativen Adresse verringert haben.
• Was tun? Betroffene Adresse und letzte Transaktionen vor dem Auffüllen prüfen.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Warnung unter (FLR/SGB): Standard 25 (0,001–1.000.000). Warnt, wenn ein lesbares natives Guthaben strikt unter diesem Betrag liegt.
• Kritisch unter (FLR/SGB): Standard 5 (0–1.000.000). Stuft einen Guthabenalarm unter diesem Betrag als kritisch ein; darf die Warnschwelle nicht überschreiten.

Verfügbarkeit und Aktualität der Überwachungsdaten.

Verfügbarkeit der Überwachung

Immer aktiv. Pausiert Provider-Alarme bei veraltetem Analyzer oder veralteten Ergebnissen.

• Was wird geprüft? Prüft immer die Analyzer-Verfügbarkeit. Fehlende, fehlerhafte oder über zehn Minuten alte Läufe bzw. Rundendaten pausieren die Provider-Auswertung.
• Warum ist das wichtig? Veraltetes Monitoring kann den Provider-Zustand nicht zuverlässig bewerten.
• Typische Ursachen: Der Analyzer kann gestoppt oder fehlgeschlagen sein oder keine vollständigen Runden mehr erhalten.
• Was tun? Analyzer-Status, letzten Lauf und Aktualität der indexierten Runden prüfen.
• Signal aktiviert: Immer an
• Erholungsmeldung senden: an

Beobachtete FTSO- und FDC-Frühwarnungen, getrennt von offiziellen Minimal-Conditions-Entscheidungen.

Anchor-Frühwarnung

Beobachtete Anchor-Treffer unter der Fensterschwelle; keine offizielle Entscheidung über Reward-Berechtigung.

• Was wird geprüft? Prüft die beobachtete Trefferquote der FTSO-Anker-Feeds im gewählten Fenster bei genügend aktuellen Stichproben. Ohne Signing-Gewicht ist die Prüfung nicht anwendbar.
• Warum ist das wichtig? Offiziell müssen Anker-Feed-Werte in 80 % der Voting-Runden je Reward-Epoche innerhalb 0,5 % vom Median liegen. Dieses Fenster ist ein Frühindikator, nicht das offizielle Ergebnis.
• Typische Ursachen: Geringe Teilnahme, Verbindungsunterbrechungen oder unvollständige Beobachtungen können den Messwert senken.
• Was tun? Vor der Provider- oder Validator-Prüfung Fenster, Beobachtungszahl und Aktualität der Quelle prüfen.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Warnung unter (%): Standard 80 % (1 %–100 %). Warnt unter diesem Prozentsatz bei genügend aktuellen Beobachtungen; Erholung benötigt zwei Prozentpunkte mehr, höchstens 100 %.
• Fenster: Standard 2 Stunden. Wählt das Beobachtungsfenster in Stunden; dies ist keine Auswertung der gesamten Reward-Epoche.
• Mindestzahl Beobachtungen: Standard 40 (10–240). Mindestens so viele Beobachtungen sind nötig, bevor der Prozentsatz ausgewertet wird.

FDC-Frühwarnung

Beobachtete FDC-Teilnahme unter der Fensterschwelle. Runden ohne Konsens sind ausgeschlossen.

• Was wird geprüft? Prüft beobachtete FDC-Teilnahme an Konsensrunden bei genügend aktuellen Stichproben; Runden ohne Konsens und Signing-Gewicht null sind ausgenommen.
• Warum ist das wichtig? Offiziell verlangt FDC erfolgreiche Teilnahme (den richtigen Merkle-Root) in 60 % der Voting-Runden je Reward-Epoche. Deine Schwelle hier kann früher warnen.
• Typische Ursachen: Geringe Teilnahme, Verbindungsunterbrechungen oder unvollständige Beobachtungen können den Messwert senken.
• Was tun? Vor der Provider- oder Validator-Prüfung Fenster, Beobachtungszahl und Aktualität der Quelle prüfen.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Warnung unter (%): Standard 80 % (1 %–100 %). Warnt unter diesem Prozentsatz bei genügend aktuellen Beobachtungen; Erholung benötigt zwei Prozentpunkte mehr, höchstens 100 %.
• Fenster: Standard 2 Stunden. Wählt das Beobachtungsfenster in Stunden; dies ist keine Auswertung der gesamten Reward-Epoche.
• Mindestzahl Beobachtungen: Standard 40 (10–240). Mindestens so viele Beobachtungen sind nötig, bevor der Prozentsatz ausgewertet wird.

Beobachtete P-Chain-Verbindung und Validator-Mitgliedschaft registrierter NodeIDs.

Validator-Verbindung

Mehrere P-Chain-Netzsichten; Warnung bis zur Prüfung im Parallelbetrieb deaktiviert.

• Was wird geprüft? Prüft beobachtete Validator-Verbindung aus mehreren P-Chain-Sichten, nicht die offizielle Uptime. Diese Warnung ist standardmäßig aus.
• Warum ist das wichtig? Staking verlangt 80 % Uptime je Reward-Epoche. Das hier ist ein beobachtetes Verbindungssignal, nicht die offizielle Uptime.
• Typische Ursachen: Geringe Teilnahme, Verbindungsunterbrechungen oder unvollständige Beobachtungen können den Messwert senken.
• Was tun? Vor der Provider- oder Validator-Prüfung Fenster, Beobachtungszahl und Aktualität der Quelle prüfen.
• Signal aktiviert: aus
• Erholungsmeldung senden: an
• Warnung unter (%): Standard 80 % (1 %–100 %). Warnt unter diesem Prozentsatz bei genügend aktuellen Beobachtungen; Erholung benötigt zwei Prozentpunkte mehr, höchstens 100 %.
• Fenster: Standard 2 Stunden. Wählt das Beobachtungsfenster in Stunden; dies ist keine Auswertung der gesamten Reward-Epoche.
• Mindestzahl Beobachtungen: Standard 40 (10–240). Mindestens so viele Beobachtungen sind nötig, bevor der Prozentsatz ausgewertet wird.

Validator nicht gelistet

Keine registrierte NodeID ist ein aktueller Validator. Fehlenden oder abgelaufenen Stake prüfen. Ohne NodeIDs nicht anwendbar.

• Was wird geprüft? Warnt nur, wenn alle bekannten registrierten NodeIDs bestätigt im aktuellen Validator-Set fehlen. Keine NodeIDs oder unbekannte Ergebnisse belegen kein Fehlen.
• Warum ist das wichtig? Ein Node, der kein aktiver Validator ist, verdient keine Staking-Rewards, und die Staking-Minimal-Condition verlangt 80 % Uptime je Reward-Epoche.
• Typische Ursachen: Die Stake-Laufzeit des Validators ist abgelaufen, der Node wurde nie als Validator eingetragen, oder die mit der Entity verknüpfte NodeID hat sich geändert.
• Was tun? Prüfe das Stake-Ende des Nodes, verlängere den Stake bei Bedarf und prüfe die mit deiner Identity verknüpfte NodeID.
• Signal aktiviert: an
• Erholungsmeldung senden: an

Persönliche unbeanspruchte Rewards der Provider-Adressen, je Epoche gebündelt.

Nicht geclaimte persönliche Rewards

Eine Sammelmeldung je Epoche über claimbare DIRECT/FEE-Rewards, mit Proofs geprüft. Delegator-Pools sind ausgeschlossen.

• Was wird geprüft? Meldet persönliche unbeanspruchte Direct- und Fee-Rewards oberhalb des Mindestbetrags einmal je Reward-Epoche; Erholung bei einem Betrag kleiner oder gleich der Schwelle.
• Warum ist das wichtig? FSP-Rewards verfallen nach 25 Reward-Epochen (rund drei Monate); nicht geclaimte Direkt- und Fee-Rewards sind dann verloren.
• Typische Ursachen: Rewards wurden beanspruchbar oder ein Claim ist im Cache noch nicht sichtbar.
• Was tun? Epoche, Betrag und Claim-Status in der Rewards-Ansicht prüfen.
• Signal aktiviert: an
• Erholungsmeldung senden: an
• Mindestmenge (FLR/SGB): Standard 1 (0–1.000.000.000). Alarm nur, wenn persönliche unbeanspruchte Rewards strikt über diesem Betrag in nativen Token liegen.