filecoin-project / filecoin-project/core-devs
🧵 Thread for FIP-0100 Starboard monitoring 📈
- Dominant language
- JavaScript
- Stars
- 37
- Forks
- 13
- PR merge metrics
- No merged PRs in 30d
Description
This concerns [FIP-0100](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0100.md). It is separate from [the FIP discussion](https://github.com/filecoin-project/FIPs/discussions/1105) since it's a technical action item rather than something that impacts the FIP itself.
The below items are starting items from @rvagg. It's expected we have a followup meeting between FilOz and Starboard to clarify any ambiguities and answer any questions. This issue we'll act as the notes/tracker for this.
---
1. **Sector `daily_fee` Field**: If you are collecting sector information, please ensure the new `daily_fee` field from `SectorOnChainInfo` is included in your data capture. Monitoring the aggregate `daily_fee` across all sectors over time will be crucial to understand the total network fee accrual.
2. **Deadline-Level Block Reward Cap**: If feasible, capturing information related to the per-deadline estimated block reward cap calculation would be valuable (i.e. the fee will be capped at 50% of a miner's estimated daily reward for the power in a deadline). While not critical, this data enhances accuracy in understanding fee application and capping behavior.
3. **Deadline daily_fee and Sector Liveness**: If you currently monitor deadline-level information, tracking the `Deadline.daily_fee` field over time and comparing it against live sector totals within deadlines could be insightful. Do you currently track sector liveness within deadlines? Monitoring this in conjunction with the new fee would be beneficial.
4. **Miner Burn in Cron**: Monitor overall miner burn rates, specifically within cron executions. While differentiating FIP-0100 related burn from other cron-based burns might be challenging, an overall increase in burn, especially when base fee is low (as expected post-NV25), should be observable and indicative of the new fee mechanism in action.
5. **Vesting Funds and Locked Funds**: If you collect `VestingFunds` data or miner state information such as `locked_funds`, these could offer additional data points. While the recent `VestingFunds` bug might impact this data slightly, monitoring `locked_funds` in miner state could still be valuable. Also note that if you are inspecting the `VestingFunds` data structure, there is a major change in this FIP for how it's stored.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.