Özet

FlareWatch, Flare Network pozisyonlarını izleyen ve takip eden bir Next.js uygulamasıdır — staking, delegasyon, ödüller ve getiri. Tanımlayıcı mimari özelliği salt okunur olmasıdır: kullanıcı finansal durumunu tutacak bir arka uç veritabanı, işlem imzalama yolu ve kullanıcı anahtarlarına programlı erişim yoktur. Tüm pozisyon verileri, istek sırasında Flare'nin zincir üstü altyapısından alınır.

Cüzdan bağlantısı (Sign-In-With-Ethereum) yalnızca hangi zincir üstü adresi sorgulanacağını belirlemek için mevcuttur. Uygulamanın yetkilendirmesi gereken zincir üstü işlemleri olmadığından, zincir üstü işlemleri yetkilendirmez.

FlareWatch neler okur ve nereden okur

FlareWatch tarafından kullanılan her sözleşme adresi, çalışma zamanında Flare'nin kanonik zincir üstü adres kaydı olan FlareContractRegistry'den çözümlenir (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). Flare yönetişimi bir sözleşmeyi taşıdığında, FlareWatch kod değişikliği olmadan bir sonraki oturumda yeni adresi alır.

Veri kaynakları, öncelik sırasına göre:

Zincir üstü (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — bakiyeler, stake edilen tutarlar, talep edilebilir ödüller ve fiyatlar için temel gerçek.
Flaremetrics API — istemci tarafında hesaplanması çok pahalı olan doğrulayıcı ve FTSO sağlayıcı metaveri.
CoinGecko — çok para birimli fiyat verisi ve pazar değeri.
Flare Block Explorer — vergi kayıtları ve ödül sınıflandırması için geçmiş işlem aramaları.

Katmanlı veri akışı

Uygulama katı bir yalnızca ileri yönde katmanlama kuralı uygular:

services → stores → hooks → components → pages

Katman	Sorumluluk
Hizmetler	İş mantığı ve veri getirme. Saf asenkron fonksiyonlar. React yok.
Depolar	Reaktif durum (Zustand). Veri tutma, veri getirme yok.
Hook'lar	Kablolama katmanı. Hizmetleri çağırma, depolara yazma. İş mantığı yok.
Bileşenler	Seçiciler aracılığıyla depolardan okuma. Kullanıcı arayüzü render etme. Hiçbir zaman getirme.
Sayfalar	Bileşim. Özellik bileşenlerini düzenleyin.

Pratik sonuç olarak, veri getirme, türetme ve işlemenin her birinin tek bir merkezi noktası vardır. Doğrulayıcı verilerine ihtiyaç duyan bir bileşen, doğrulayıcı durumuna abone olur — hiçbir zaman Flaremetrics API'sini doğrudan çağırmaz.

Ödül akışları

FlareWatch dört bağımsız ödül akışını takip eder. Bunlardan herhangi birini tek bir havuz olarak ele almak önemli ölçüde verim yanlış hesaplamaya neden olur; bu nedenle her biri ayrı şekilde kaynak alınır ve hesaplanır.

Akış	Kadans	Sona Erişi
FTSO delegasyonu ödülleri	Her ödül dönemi (~3,5 gün)	~87.5 days
Doğrulama Ödülü Yöneticisi (VRM)	Her 4 ödül dönemi (~14 gün)	Asla
Yansıtılan stake (P-Chain → FSP)	Her ödül dönemi (~3,5 gün)	~87.5 days
FlareDrop	Sonlandırıldı	—

P-Chain stake ana parası kilit açıldığında geri döndürülür ve ödül akışı olmasa da, hesap bakiyelerinde görünmektedir.

Getiri tahmini

FlareWatch üç katmanlı bir verim modeli kullanır. Her katman, kullanıcının tahmin hassasiyetini anlaması için UI'da etiketlenmiştir.

Katman 1 — Gerçek veri. RewardManager sözleşmesi aracılığıyla zincir üstü talep edilebilir ödüller. Bu, zincir üstünde beklemeye alan gerçek değerdir.
Katman 2 — Veri odaklı. Talep edilebilir sıfır olduğunda, FlareWatch cüzdanın işlem geçmişinden son beş taleplerinin medyanını bir sonraki dönem tahmini olarak kullanır.
Katman 3 — Formül geri planı. Talep geçmişi olmadığında, wflrBalance × FTSO_DELEGATION_APR / epochsPerYear geçerli ağ durumundan matematiksel bir oran projelendirir.

FlareWatch, yerli Flare staking ve FTSO delegasyonu için tek bir APY gösterir: en son ödül epochunun FLR başına ücretler düşüldükten sonra ödemesi, yıllıklandırılmış (× 365 / 3.5 gün). Bileşiklendirilmez, çünkü Flare ödülleri talep edilmeden önce kazanabilir hale gelemez ve diğer Flare explorer'larının yayınladığı rakamla eşleşir. Otomatik bileşikelenen DeFi pozisyonları (Sceptre sFLR gibi) kendi protokol APY'sini gösterir.

Güvenlik modeli — bir bakışta

Güvenlik, Güvenlik Özellikleri sayfasında ayrıntılı olarak ele alınmıştır. Ana noktalar şunlardır:

Hesaplar değil, cüzdan tabanlı kimlik. Şifre yok, e-posta bağlantılı kimlik yok. Cüzdan bağlantısı sorgulanacak adresi tanımlar.
Tasarımı gereği salt okunur. Uygulama hiçbir zaman anahtarları tutmaz, işlemleri imzalamaz ve kullanıcı adına akıllı sözleşmelerle etkileşimde bulunmaz.
Sunucu tarafı oturum iptal. Oturum kapatma sunucuda uygulanır, böylece çalınan bir oturum çerezi kullanıcı oturum kapattığında hemen çalışmayı durdurur — 24 saatlik süre dolana kadar beklemez.
Cüzdan başına sahiplik kontrolü. Cüzdan başına durumu okuyan veya yazan her API yolu, kimliği doğrulanmış cüzdanın hedef cüzdanla eşleştiğini doğrular. Kullanıcı verileri için yönetici geçersiz kılma yolu yoktur.
Derinlemesine HTTP başlıkları. Strict-Transport-Security, kısıtlayıcı bir Content-Security-Policy, X-Frame-Options DENY ve sıkı bir Permissions-Policy her yanıtta gönderilir.

Test

Uygulama, her regresyonun gerçekleşeceği varsayılarak test edilir — çünkü FlareWatch'un önemsediği regresyon türleri (finansal hesaplamalar hafif şekilde yanlış) gönderildiklerinde sessizdir. Kapsam alanları:

Staking ve FTSO delegasyon APY matematiki.
Birden fazla yargı alanında para birimi biçimlendirmesi.
FLR miktarı, yüzde ve tarih biçimlendirmesi.
Eşik renk-bant mantığı (böylece bir "yeşil" teslimat sessizce kehribar rengine dönüşmez).
Yargı alanları arasında vergi son tarih hesaplamaları.

Test paketi her push işleminde CI'da çalışır.

Altyapı

FlareWatch, Vercel üzerinde çalışır. Frontend, önbellekleri ısıtan cron işleri ve bu önbellekleri tutan Redis tabanlı anahtar-değer deposunun tümü platformı paylaşır. Bu seçim kasıtlıdır: ölçekte sıfır operasyonel maliyet ve tüm dağıtım yüzeyi bir sağlayıcı aracılığıyla denetlenebilir.

services/ katmanı kasıtlı olarak çerçeve bağımsızdır. FlareWatch hiçbir zaman Vercel'den ayrılırsa, iş mantığı hizmetleri saf async fonksiyonlarıdır ve onunla birlikte taşınır.

Daha fazla okuma

Güvenlik Özellikleri — kimlik doğrulama, yetkilendirme, hız sınırlaması, başlıklar, denetim geçmişi.
Safeguards Genel Bakışı — FlareWatch'un kendisine uyguladığı mimari kurallar ve nedenleri.