🧵 Thread for FIP-0100 Starboard monitoring 📈

[BigLep]

This concerns FIP-0100. It is separate from the FIP discussion 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.

[BigLep]

2025-03-06 conversation notes between FilOz and Starboard:

• @rvagg gave a verbal overview
• Q: how often is daily_fee updated? (Rod gave the details, but effectively not very often like how "daily reward" doesn't really change. Normal behavior is it doesn't change, but a snapping/NIPoRep workflow would induce changes.)
• Q: does it change if sector extends? Only if QAP changes.
• Q: (num 4) how often is the burn? If a miner is using all 48 deadlines, they're paying fee 48 times a day. Cron kicks in a a proving window. With time and more sectors, we should be seeing constant burn effectively.
• Discussion of the bug in No vesting during cron builtin-actors#1594 and how this will get fixed. It means ~400k is going to get unlocked as a result (which should have been unlocked).
• Callout about the structure change of VestingFunds. See https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0100.md#optimization-of-vestingfunds (Not an issue if you consume this through go-state-types as the change is abstracted away.)
• Discussion on the "lazy migration strategy" discussed in https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0100.md#fee-implementation
• Discussion on what gets migrated (https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0100.md#migration ).
  • We're not doing a lazy migration of Deadline.
• Q: Do you track calibration like mainnet?
  • Yes
  • There is a minor detail about how circulating supply is 0: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0100.md#special-handling-for-calibration-network
  • (if you want all the gory details... fix(build)!: adjust FilReserved for FIP-0100 for non-mainnet lotus#12938 )
• Here is a Lotus branch that is working feat: nv25 and nv26 - fip-0100 (and some FIP-0098) lotus#12932

[rvagg]

filecoin-project/go-state-types#371 has some additional changes worth noting too; FIP-0098 makes 3 fields in SectorOnChainInfo nullable: ExpectedDayReward, ExpectedStoragePledge, ReplacedDayReward. New sectors should end up with a nil when decoding those after the network upgrade.

[irenegia]

@BigLep
It would be great if Starboard could add a tool to monitoring the number of nonzero FeeDebt case for active miners.

Motivation: We know that for new miners that will join the network afte nv25, the new fee (FIP100) will cause the nonzero FeeDebt situation (unless they add tokens in their actor balance). And moreover for small to medium size miners that do not win leader election every day, the nonzero FeeDebt may be more frequent to happen due to the fact that the new fee is paid daily while block reward is received every x> 1 days.

[BigLep]

@irenegia : makes sense - thanks for flagging

@Terryhung and beng-starboard: does that seem reasonable to you to add? Is this something you can take on?

[rvagg]

I'm just stumbling across this and it's a great page with some good live data and some of it is relevant to the new fees: https://observablehq.com/@starboard/a-primer-to-filecoin-circulating-supply/2, "Edited Jul 21, 2022", but it's still connected to live data sources and apparently working well.

There's a section titled "1.2.7 Network Transaction Fees" which would be awesome to have the daily fee added to. Unfortunately it's going to be tricky disambiguating it from regular burn. The "2.Filecoin Circulating Supply Example Simulation" has a burn plot so it should show up as a bump in that line.

---

Regarding inspecting the state and chain activity for fees: I built a tool in lotus-shed that lets me inspect a specific miner to (1) inspect their sectors' daily fees, (2) perform an accounting check on the sums of those fees in their deadlines and expiration sets and (3) inspect cron execution to find evidence of fee payment, including calculating their expected 24h block reward for those sectors to account for the fee cap. You can find the code here: https://github.com/filecoin-project/lotus/blob/master/cmd/lotus-shed/miner-fees.go; unfortunately it requires a StateCompute to inspect the cron execution of a deadline, and then you need to go digging around in the trace to find the cron->miner->burn trace to see it being paid. But it goes to that level of detail just to check that everything is working, and the burn could also be burning penalties so it's not 100% fee burn right there. But the tool shows a few different angles from which to capture the fee information. I don't think we know yet how important the 50%BR cap is going to be and whether it'll be invoked much, or at all, on mainnet. Maybe we can ignore the complexity of having to calculate that to account for fees and just use the deadline or sector-level information to tell us and we can extrapolate from there how much was being burnt.

@Terryhung let me know if you want to hop on a Zoom and talk through any of this.

[Terryhung]

Hi @rvagg ,

Just to clarify — the "daily fee," do you mean summing up the daily fees of each sector from all miners?

[rvagg]

@Terryhung yes, I think so, but I also think the terminology could have been improved when we shipped this, "daily proof fee" or "daily sector fee" might be better. My point was that it would be nice to see the fee portion of the burn metrics if it were possible to do that somehow. The roughest version of this would be to sum up all of the fees from all live sectors and that's what we would expect to be burnt each day. It may not be 100% accurate (due to the BR cap, which we don't expect to see used much, if at all), but it'll be close enough.

[Terryhung]

@rvagg ,
Let me sum up all of the fess from all live sectors first! Thanks

[BigLep]

I'm going to close this out because we have https://dashboard.starboard.ventures/transactions-usage#protocol-revenue

This Protocol Revenue panel is the closest proxy we have. Because fees are paid by burn at cron they are a bit hard to pick apart from penalties but they ought to make up the largest portion of the "Proof and Penalty Fee" part of this chart. Over time we expect to see this grow.

@rvagg or @Terryhung : let me know if you disagree or think there is more work we need to do for this one.

[BigLep]

Per slack here, it sounds like we need to push on this further. I'm reopening.

@Terryhung : is extracting a "purer" metric more feasible? When do you think you'll get to it? Is there a tracking issue we can watch?