Architektur

Übersicht

FlareWatch ist eine Next.js-Anwendung, die Flare-Network-Positionen überwacht und verfolgt – Staking, Delegation, Rewards und Rendite. Das prägende Architekturmerkmal ist, dass sie schreibgeschützt ist: es gibt keine Backend-Datenbank, die den finanziellen Status des Benutzers speichert, keinen Transaktionssignierungspfad und keinen programmgesteuerten Zugriff auf Benutzerschlüssel. Alle Positionsdaten werden zum Zeitpunkt der Anfrage aus Flares On-Chain-Infrastruktur bezogen.

Die Wallet-Verbindung (Sign-In-With-Ethereum) dient ausschließlich der Identifikation der abzufragenden On-Chain-Adresse. Sie autorisiert keine On-Chain-Aktionen, da die Anwendung keine On-Chain-Aktionen zu autorisieren hat.

Was FlareWatch liest und woher

Jede von FlareWatch verwendete Vertragsadresse wird zur Laufzeit aus der FlareContractRegistry aufgelöst, Flares kanonischem On-Chain-Adressregister (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). Wenn Flare-Governance einen Vertrag verschiebt, erhält FlareWatch die neue Adresse in der nächsten Sitzung ohne Code-Änderung.

Datenquellen in Prioritätsreihenfolge:

• On-Chain (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) – Quelle der Wahrheit für Salden, Stakes, einfordbare Belohnungen und Preise.
• Flaremetrics API – Validator- und FTSO-Provider-Metadaten, deren Berechnung client-seitig zu teuer ist.
• CoinGecko – Multi-Währungs-Preisdaten und Marktkapitalisierung.
• Flare Block Explorer – Historische Transaktionsabfragen für Steuerdatensätze und Reward-Klassifizierung.

Mehrschichtiger Datenfluss

Die Anwendung erzwingt eine strikte Schichtenregel in eine Richtung:

services → stores → hooks → components → pages

Der praktische Effekt ist, dass Abrufen, Ableitung und Rendering jeweils ein zentrales Zuhause haben. Eine Komponente, die Validator-Daten benötigt, abonniert den Validator-Status – sie ruft die Flaremetrics-API nie selbst auf.

Reward-Streams

FlareWatch verfolgt vier unabhängige Reward-Streams. Die Behandlung eines dieser Streams als einzelner Pool führt zu erheblichen Renditefehlberechnungen, weshalb jeder separat beschafft und berechnet wird.

Der P-Chain-Stake-Principal wird bei der Freigabe zurückgegeben und ist kein Reward Stream, obwohl er in den Kontoguthaben angezeigt wird.

Renditeberechnung

FlareWatch verwendet ein dreistufiges Yield-Modell. Jede Stufe wird in der Benutzeroberfläche gekennzeichnet, damit der Benutzer die Genauigkeit der Schätzung versteht.

• Stufe 1 — Grundwahrheit. On-Chain abrufbare Rewards über den RewardManager-Vertrag. Dies ist echter Wert auf der Blockchain, der zum Abheben bereit ist.
• Stufe 2 — Datengestützt. Wenn kein abrufbarer Wert vorhanden ist, verwendet FlareWatch den Median der letzten fünf Abhebungen aus der Transaktionshistorie des Wallets als Schätzung für die nächste Epoche.
• Stufe 3 — Formelfallback. Wenn keine Abhebungshistorie vorhanden ist, projiziert wflrBalance × FTSO_DELEGATION_APR / epochsPerYear einen mathematischen Satz aus dem aktuellen Netzwerkstatus.

FlareWatch zeigt eine einzelne APY für natives Flare-Staking und FTSO-Delegation: die Auszahlung pro FLR der neuesten Reward-Epoche nach Gebühren, annualisiert (× 365 / 3,5 Tage). Sie ist nicht zusammengesetzt, da Flare-Rewards beansprucht werden müssen, bevor sie Rendite erbringen, und sie entspricht der Kennzahl, die andere Flare-Explorer veröffentlichen. DeFi-Positionen, die automatisch zusammengesetzt werden (wie Sceptre sFLR), zeigen ihre eigene Protokoll-APY.

Sicherheitsmodell — auf einen Blick

Sicherheit wird auf der Seite Security Features ausführlich behandelt. Die wichtigsten Punkte sind:

• Wallet-basierte Identität, keine Konten. Keine Passwörter, keine E-Mail-gekoppelte Identität. Die Wallet-Verbindung identifiziert, welche Adresse abgefragt werden soll.
• Standardmäßig schreibgeschützt. Die App hält niemals Schlüssel, signiert niemals Transaktionen und interagiert niemals mit Smart Contracts im Namen des Benutzers.
• Serverseitige Sitzungswiderruf. Die Abmeldung wird auf dem Server durchgesetzt, sodass ein gestohlenes Session-Cookie sofort nach der Abmeldung des Benutzers nicht mehr funktioniert – nicht bei Ablauf nach 24 Stunden.
• Verwaltungszugriff pro Wallet. Jede API-Route, die Zustand pro Wallet liest oder schreibt, überprüft, dass die authentifizierte Wallet mit der Ziel-Wallet übereinstimmt. Es gibt keinen Admin-Override-Pfad für Benutzerdaten.
• Defense-in-Depth HTTP-Header. Strict-Transport-Security, eine restriktive Content-Security-Policy, X-Frame-Options DENY und eine enge Permissions-Policy werden in jeder Antwort mitgeliefert.

Tests

Die Anwendung wird so getestet, als würde jede Regression auftreten – denn die Art von Regressionen, die FlareWatch interessieren (finanzielle Berechnungen, die subtil falsch sind), sind lautlos, wenn sie ausgeliefert werden. Testabdeckungsbereiche:

• Staking- und FTSO-Delegations-APY-Mathematik.
• Währungsformatierung über mehrere Gerichtsbarkeiten hinweg.
• FLR-Betrag, Prozentsatz und Datumsformatierung.
• Logik für Farbband-Schwellenwerte (damit eine "grüne" Auslieferung nie stillschweigend zu Bernstein wechselt).
• Steuerterminberechnungen über Gerichtsbarkeiten hinweg.

Die Test-Suite läuft in CI bei jedem Push.

Infrastruktur

FlareWatch läuft auf Vercel. Das Frontend, die Cron-Jobs, die Caches aufwärmen, und der Redis-gestützte Schlüssel-Wert-Speicher, der diese Caches speichert, teilen sich die Plattform. Die Wahl ist bewusst: null Betriebskosten bei Skalierung und die gesamte Bereitstellungsfläche ist durch einen Anbieter überprüfbar.

Die services/-Schicht ist absichtlich framework-unabhängig. Wenn FlareWatch jemals von Vercel wegzieht, sind die Business-Logic-Services reine asynchrone Funktionen und ziehen mit ihr.

Weitere Ressourcen

• Sicherheitsfunktionen – Authentifizierung, Autorisierung, Ratenbegrenzung, Header, Prüfverlauf.
• Schutzmaßnahmen-Übersicht – die Architekturregeln, die FlareWatch sich selbst auferlegt, und warum.