Arsitektur

Ringkasan

FlareWatch adalah aplikasi Next.js yang memantau dan melacak posisi Flare Network — staking, delegasi, reward, dan yield. Fakta arsitektur yang menentukan adalah bahwa ini bersifat read-only: tidak ada database backend yang menyimpan status keuangan pengguna, tidak ada jalur penandatanganan transaksi, dan tidak ada akses terprogram ke kunci pengguna. Semua data posisi bersumber dari infrastruktur on-chain Flare saat permintaan.

Koneksi dompet (Sign-In-With-Ethereum) ada hanya untuk mengidentifikasi alamat on-chain mana yang akan dipertanyakan. Ini tidak mengotorisasi tindakan on-chain karena aplikasi tidak memiliki tindakan on-chain untuk diotorisasi.

Apa yang dibaca FlareWatch, dan dari mana

Setiap alamat kontrak yang digunakan FlareWatch diselesaikan saat runtime dari FlareContractRegistry, registri alamat on-chain kanonik Flare (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). Ketika tata kelola Flare memindahkan kontrak, FlareWatch mengambil alamat baru pada sesi berikutnya tanpa perubahan kode.

Sumber data, berdasarkan prioritas:

• On-chain (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — kebenaran dasar untuk saldo, staking, reward yang dapat diklaim, dan harga.
• Flaremetrics API — metadata validator dan penyedia FTSO yang terlalu mahal untuk dihitung di sisi klien.
• CoinGecko — data harga multi-mata uang dan kapitalisasi pasar.
• Flare Block Explorer — pencarian transaksi historis untuk catatan pajak dan klasifikasi reward.

Alur data berlapis

Aplikasi menerapkan aturan layering satu arah yang ketat:

services → stores → hooks → components → pages

Efek praktisnya adalah bahwa pengambilan data, derivasi, dan rendering masing-masing memiliki satu rumah. Komponen yang membutuhkan data validator berlangganan state validator — komponen tidak pernah memanggil API Flaremetrics itu sendiri.

Alur reward

FlareWatch melacak empat aliran reward independen. Memperlakukan salah satu dari ini sebagai satu pool menyebabkan kesalahan hitung hasil yang signifikan, itulah sebabnya masing-masing bersumber dan dikomputasi secara terpisah.

Principal stake P-Chain dikembalikan saat unlock dan bukan aliran reward, meskipun muncul di saldo akun.

Estimasi yield

FlareWatch menggunakan model yield tiga tingkat. Setiap tingkat diberi label di UI sehingga pengguna memahami presisi estimasi.

• Tingkat 1 — Ground truth. Reward yang dapat diklaim on-chain melalui kontrak RewardManager. Ini adalah nilai nyata yang berada di on-chain, menunggu untuk diklaim.
• Tingkat 2 — Data-driven. Ketika claimable nol, FlareWatch menggunakan median dari lima klaim terakhir dari riwayat transaksi dompet sebagai estimasi epoch berikutnya.
• Tier 3 — Fallback formula. Ketika tidak ada riwayat klaim, wflrBalance × FTSO_DELEGATION_APR / epochsPerYear memproyeksikan tingkat matematis dari kondisi jaringan saat ini.

FlareWatch menampilkan single APY untuk native Flare staking dan FTSO delegation: payout latest reward epoch per FLR setelah biaya, diannualisasi (× 365 / 3,5 hari). Ini tidak dimajemukkan, karena reward Flare harus diklaim sebelum dapat menghasilkan, dan itu cocok dengan figure yang explorer Flare lain publikasikan. DeFi positions yang auto-compound (seperti Sceptre sFLR) menampilkan protocol APY mereka sendiri.

Model keamanan — sekilas

Keamanan dibahas secara detail di halaman Fitur Keamanan. Poin utamanya adalah:

• Identitas berbasis dompet, bukan akun. Tanpa kata sandi, tanpa identitas terkait email. Koneksi dompet mengidentifikasi alamat mana yang akan dikueri.
• Baca-saja menurut desain. Aplikasi tidak pernah memegang kunci, tidak pernah menandatangani transaksi, dan tidak pernah berinteraksi dengan kontrak pintar atas nama pengguna.
• Pencabutan sesi di sisi server. Keluar dipaksakan di server, sehingga cookie sesi yang dicuri berhenti berfungsi segera setelah pengguna keluar — bukan pada kedaluwarsa 24 jamnya.
• Gating kepemilikan per-dompet. Setiap rute API yang membaca atau menulis status per-dompet memverifikasi bahwa dompet yang terautentikasi cocok dengan dompet target. Tidak ada jalur penggantian admin untuk data pengguna.
• Header HTTP pertahanan berlapis. Strict-Transport-Security, Content-Security-Policy yang ketat, X-Frame-Options DENY, dan Permissions-Policy yang ketat dikirim pada setiap respons.

Pengujian

Aplikasi diuji seolah-olah setiap regresi akan terjadi — karena jenis regresi yang FlareWatch pedulikan (perhitungan keuangan yang sedikit salah) bisu ketika dikirim. Area cakupan:

• Staking dan FTSO delegation APY math.
• Pemformatan mata uang di berbagai yurisdiksi.
• Pemformatan jumlah FLR, persentase, dan tanggal.
• Logika pita warna ambang batas (sehingga pengiriman "hijau" tidak pernah diam-diam beralih ke amber).
• Komputasi batas waktu pajak di berbagai yurisdiksi.

Rangkaian tes berjalan di CI pada setiap push.

Infrastruktur

FlareWatch berjalan di Vercel. Frontend, cron job yang menghangatkan cache, dan penyimpanan key-value yang didukung Redis yang menyimpan cache tersebut semuanya berbagi platform. Pilihan ini disengaja: biaya operasional nol dalam skala besar, dan seluruh permukaan deployment dapat diaudit melalui satu penyedia.

Layer services/ sengaja framework-independent. Jika FlareWatch pernah bermigrasi keluar dari Vercel, service logika bisnis adalah fungsi async murni dan bergerak bersama dengannya.

Bacaan lebih lanjut

• Fitur Keamanan — autentikasi, otorisasi, rate limiting, header, riwayat audit.
• Gambaran Umum Safeguards — aturan arsitektur yang FlareWatch paksakan pada dirinya sendiri, dan mengapa.