Reduce onboarding gas & align value accrual by removing batch balancer and replacing it with a per-sector fee

[irenegia]

Context and Motivation

In the ongoing effort to reduce per-sector onboarding gas costs (see #1092), we have identified the following active work streams:

• Supporting the DDO Pipeline: For example, adding DDO deal tracking capabilities to Spark.

• Storage Gas Optimizations and Miner Configuration Improvements: Tracking this work here;

• Enabling Full Adoption of Batching and Aggregation to Scale Onboarding Growth: This involves ensuring that batching for precommit and batching/aggregation for provecommit are always rational (ie, cost-effective for SPs).

This new discussion focuses specifically on the third point—making batching and aggregation pipelines cost-effective while aligning network value accrual with onboarding growth. Currently, the cost-effectiveness of these pipelines is governed by the BatchBalancer mechanism, which is tied to the base fee. In the sections below, we provide an overview of the current system, highlight its limitations, and propose a practical solution to address these challenges and enable fast progress. This proposal builds on previous work done by CryptoNet (see here and #587).

Filecoin's current fee structure consists of two main components:

• Gas Fees: As in other blockchains, gas fees mediate access to limited blockchain execution capacity. These fees are burned, generating network revenue proportional to the execution resources used.

• Batch Balancer Mechanism: Beyond blockchain execution, the Filecoin network provides a storage-auditing service to SPs through the proofs of storage verified on-chain. Historically, before proof aggregation, each proof verified a single unit of storage (sector), meaning gas fees captured the value of the storage auditing service. However, the introduction of proof aggregation (where one proof audits multiple sectors) disrupted this alignment. The batch balancer was introduced to address this misalignment but has become outdated, and, as recent work on gas onboarding optimization (Onboarding rate and gas optimizations #1092) highlights, it now acts as a bottleneck to fully adopting aggregation and batching.

Problem Statement: Gas fees – a system primarily intended to charge for execution resources – alone do not properly capture network value for Filecoin, negatively impacting the overall Filecoin economy. Filecoin value accrual via fees should grow proportionally to network adoption and demand, and be resilient to technical optimizations that reduce gas fees and increase chain bandwidth. While the batch balancer mechanism tried to solve this, at the same time it creates these inefficiencies:

• It discourages full adoption of batching and aggregation by making these operations less rational (cost-effective). Batching and aggregation improves the overall efficiency of Filecoin, and increases the onboarding capacity of the network.

• It couples gas fees with storage auditing in a way that limits predictability and increases exposure to base fee volatility. Gas fee pricing is designed to prevent the network from overusing execution resources; it should not be so directly tied to onboarding levels.

• It poses challenges for aligning technological improvements (such as optimizations that reduce gas congestion) with economic incentives (value accrual alignment with network growth).

Proposal and Effects

To address these issues, we propose removing the batch balancer mechanism and replacing its value accrual effect with a per-sector fee, separate from gas fees. This change has multiple benefits:

1. Rational Batching and Aggregation
   • With batching (for precommit) and aggregation (for provecommit) fully adopted, we expect a 30% reduction in per-sector onboarding gas.
   • Lower onboarding gas increases the network’s onboarding rate capacity, allowing Filecoin to surpass the current ~3PiB/day rate without elevating base fee.
2. Improved Predictability and User Experience
   • By separating gas fees (blockspace costs) from service fees (onboarding costs), we create a resilient system less prone to base fee spikes, offering predictable and fair costs to SPs.
   • The network can guarantee a smoother user experience, with clear boundaries between congestion control (via base fees) and the payment of costs of other additional services unrelated to congestion.
3. Alignment with Long-Term Network Economics
   • Burning a per sector fee, the network is able to properly capture value for the storage auditing service (ie, proportionally to the storage demand).
   • Future optimizations in proofs or onboarding throughput will no longer risk destabilizing the network’s economic alignment. This ensures the Filecoin protocol can continue to reduce costs for SPs while capturing value for the network.

Fee Design Principles

The fee should accord with the following design goals:

1. Simplify the system to improve predictability
   • Introducing a per-sector fee should help reduce the likelihood of network shocks caused by unpredictable base fee volatility.
   • Service Providers should be able to reason about future fees, rewards, and ROI.
   • A simpler system is easier to maintain, requiring fewer manual updates.
2. Increase & Align Network Value Accrual
   • As demand for Filecoin storage increases, cumulative fees burnt should grow proportionally, reflecting the added value to the ecosystem.
   • Service fees should prevent the long-term decline of burn fees, ensuring economic sustainability as gas fees per sector decrease with technological advancements.
   • Burn fees reduce the supply of FIL permanently, equally distributing the value accrued by the network to FIL holders and earners.
3. Avoiding More Onboarding Rate Limits
   • The fee should not introduce new bottlenecks that constrain the network’s ability to onboard data.
4. Fast Alignment + Delivery
   • Unblocking network onboarding rate and gas fee predictability require quick improvements to unlock network growth.
   • Therefore the network needs a simple, reasonable, and effective solution that can be aligned on and implemented quickly to fit into the next network upgrade.
   • Take a launch-observe-iterate approach to landing simple improvements now, and be able to improve with more data-driven iterations in the future.

Proposal Directions

We are exploring two high-level fee models:

1. Flat per-sector fee. For example,: each sector burns 1% of the corresponding expected block rewards or pledge collateral. This simple model offers predictability and consistency.
2. Dynamic per-sector fee: Eg: the fee updates daily based on the delta in Quality Adjusted Power (QAP) from the previous day. This approach adjusts fees dynamically to align with storage demand trends such that a network growing faster charges higher fees. This more closely aligns network value accrual, but at the expense of simplicity and predictability.

We are evaluating variations of these models that tie fees to broader economic indicators, such as circulating and total token supply. Proposals are being evaluated based on how well they achieve the Fee Design Principles above.

Conclusion

This proposal introduces a more predictable and rational fee structure that replaces the batch balancer with a per-sector fee, providing Storage Providers with a cost structure that is more stable and easier to plan around. By decoupling gas fees from service fees, this should better capture network value, encourage technological innovation and optimization, and ensure the long-term economic sustainability of the Filecoin network.

Please give your initial thoughts and questions; this is a work in progress, and your feedback will help ensure this approach benefits all parts of the Filecoin ecosystem.

[mjroddy]

Thanks @irenegia agree on this

Just on 2 - dynamic pricing.

I'm not sure on the merits of this approach. I don't think we should be disincentivising onboarding via a higher fee unless there are constraints (like with gas fees). If Filecoin found rapid traction what would be the benefit of increasing the fee at the expense of possibly slowing that down?

Adjusting down in periods of declining growth I could understand but this also happens naturally with more of the simple rewards being distributed amongst the lower QAP.

[momack2]

Good question. The merits are similar to gas market pricing that charges higher fees when the network is under heavy load - allowing the value accrual of the network to scale faster when the network is growing and under heavy demand. Having a dynamic fee would allow balancing the fees vs onboarding demand - aiming to estimate a "market clearing price" (that offers discounts when network growth is slow, and scales value accrual when demand is high). The downside is the complexity of getting those dynamic fee parameters correctly calibrated and avoiding disincentivizing onboarding as you flag as a risk.

[mjroddy]

Sorry @momack2 didn't see this.

That make sense particularly if you have a heavy load on the network and you need to subdue demand to ensure a decent UX which is the case for gas.

for storage onboarding I don't think that's the case? We would be subduing demand for the sake of capturing higher margin not UX.

This could be Reasonable but my sense is Filecoin would benefit more from a higher onboarding rate than a potentially suppressed one but capturing a bit of extra FIL via the higher fees.

Anyway I think this point is void as the fee is based on CS which makes a lot of sense to me...increasing when excess supply is in the market.

Supporting this and hopefully more economic improvements!

[momack2]

Moving the question from @beck-8 in the FIP draft here for discussion: #1113 (comment)

@irenegia Thank you for your reply.
Can you express in numbers how much this fee is? How much is the daily fee? How much is the 540-day sector fee? Is the batch fee higher or lower than before?

[beck-8]

1. How is CS calculated?
2. 0.028 It seems to be more expensive than it used to be. And no renewal is included.

[momack2]

1. you can see the definition for Circulating Supply on both Calibration net and Mainnet here: https://github.com/filecoin-project/FIPs/blob/irenegia-removeBatchBalancer/FIPS/fip-removeBatchBalancer.md#special-handling-for-calibration-network
2. (one order of magnitude smaller -- ~0.0028 FIL for a 540-day sector) - this will scale up or down depending on the actual sector length. On day 1, this fee would only be ~0.00000518518 FIL per day

[beck-8]

Okay, I understand. 100,000 sectors will cost an additional 280 FILs in 540 days.

[rvagg]

File has been renamed, the above link for the CS calculation is now: https://github.com/filecoin-project/FIPs/blob/irenegia-removeBatchBalancer/FIPS/fip-0100.md#special-handling-for-calibration-network

[irenegia]

Just want to clarify that:

• 100,000 CC or non-verified deal sectors will cost an additional 280 FILs in 540 days.
• 100,000 FIL+ deal sectors will cost an additional 2800 FILs in 540 days.

See #1105 (comment)

[momack2]

Flagging here that there is a live FIP Draft for review of this proposed change! Please review FIP-0100 at #1113 and add questions and comments for further discussion here!

[momack2]

Here is the Post Event Summary from the Monday Feb 10 Filecoin AMA: https://docs.google.com/document/d/1f4QPS4Hjx_he9OKxzZpVZGHcA3pGz_J6DWTIknw4rmM/edit

❓ FAQs from the Conversation

Economic and Network Impact

• What is the impact of this change on FIL token supply over the next 10 years?
  • The fee will burn FIL tokens over time, reducing the circulating supply.
  • Estimated burn: 50M FIL in 10 years (current growth rate), 20M–70M FIL (various scenarios).
• How do Filecoin's storage capacity, adoption rate, and gas fee optimisation impact FIL's intrinsic value?
  • The proposal makes onboarding costs more predictable and increases onboarding capacity.
  • Reduces FIL supply over time, which may impact FIL's value & exchange rate.
• Is there a projected sustainable FIL price range based on network demand in 2025?
  • No direct speculation on price.
  • However, reducing FIL supply may influence market demand.
  • A model could be developed to explore economic effects.

Protocol and Storage Provider (SP) Impact

• What does this change mean for storage providers (SPs)?
  • SPs will have more predictable onboarding costs.
  • Gas units reductions of ~30% if batching and proof aggregation are fully adopted.
  • Less exposure to base fee spikes.
• Will SPs need to calculate payments daily?
  • No. The per-sector fee is calculated once at onboarding and remains constant.
  • As a concrete example, for a sector onboarded today, the daily payment is ~5000 nanoFil.
• How can SPs determine the best provecommit timing under the new system?
  • The fee depends on the circulating supply at onboarding time.
  • This is similar to how SPs currently decide when to onboard based on initial pledge costs.
• How does this impact long-term SP profitability?
  • A more stable and predictable fee helps SPs plan ahead.
  • December 2024’s base fee spike example was cited as something this change should prevent.
  • A FIL return model is being developed to provide better estimates.

Technical and Network Functionality

• Are there unintended consequences of removing the batch balancer?
  • Expected outcome: higher onboarding rates, better batching and proof aggregation efficiency.
  • No significant risks of increased network congestion were identified.
• How will this change affect client storage costs?
  • Reduces upfront onboarding costs, making Filecoin more attractive to clients.
  • Predictability for SPs allows more stable pricing for clients.
• How does the new fee model compare to a fixed or dynamic model?
  • The per-sector fee is dynamic but predictable based on circulating supply.
  • It avoids frequent adjustments while still adapting to network conditions.

Gas Fee and Base Fee Considerations

• Will this change affect the base fee mechanism?
  • No, the base fee will still function normally.
  • This change allows the self-imposed limit to the onboarding rate via batchbalancer to avoid increasing base fee or limiting onboarding
• Will the new proposal affect base fee volatility?
  • Yes, it should make base fee fluctuations related to onboarding less likely to happen.
  • Eliminates unnecessary costs that previously made batching and aggregation less efficient.

Implementation and Timeline

• How does this change the complexity of the protocol?
  • Simplifies the system, making future upgrades easier.
  • It avoids hard-coded values that require frequent adjustments.
• What is the timeline for implementation?
  • Targeting Network Upgrade NV25 in April 2025.
  • Community feedback deadline: February 14, 2025.
  • Implementation is expected within two weeks after approval.
• Could this proposal be ready in time for NV25?
  • Yes, the team is pushing for it.
  • The proposal is currently in "Ready for Review" status here
  • Developers and the community are encouraged to provide final feedback.

[Stebalien]

I have several questions around where/how the fee is paid. First up:

1. Does the fee come from the caller when submitting WindowedPoSt messages, like gas?
2. Does the fee come from the miner actor?

The answer is (2) as far as I know, but I wanted to be explicit here.

Second, are fees charged for all partitions, even if a partition isn't proven (for example, an SP skips a proof)? This matters because, if an SP skips a proof, there won't be a WindowedPoSt message. We'd have to charge the remainder of the Fee in cron (which we could do without too much trouble).

Third, assuming we're deducting from the miner actor, how are we accounting for these fees?

1. The current onboarding fee must come from unlocked funds (the funds available to withdraw, as pledge, etc.) There must be enough unlocked funds in the miner actor to cover it.
2. Fault fees etc. come from vesting rewards first, then from unlocked balance. If there are insufficient funds on both buckets, fee debt is added (which must be paid back before withdrawing, sealing, unlocking pledge, etc.). The fee debt is ultimately backed by pledge (although it can technically rise above the pledge).

Option (2) would, IMO, simplify SP operations but I'm not sure if that has the right incentive structure. I also really don't want SPs to fail windowed post because they haven't topped up funds for fees.

Furthermore, if we're charging fees in cron (e.g., because the SP skipped a proof), we'd have to go with option (2) at that time because we can't fail to charge the fee in cron.

[beck-8]

For a small SP, it may not generate blocks for several days. But it needs to pay every day. In this case, the user needs to ensure that there is sufficient funds in the miner's available balance? @rvagg

[beck-8]

If so, the newly packaged SP may need to be reminded, otherwise, he will get deeper and deeper into trouble.

[rvagg]

You're right @beck-8, there will likely be a bootstrap period where a miner doesn't quite have enough power to start winning block rewards but has onboard sectors that are attracting a fee. So boostraping a miner will involve putting at least a small amount of FIL in the miner's balance. But given the block reward power limit is so small, and fees are proportional to power, the total fees payable should be very small. This is probably something that needs to be clearly documented somewhere about the process of bootstraping a new miner actor.

[irenegia]

I run the math (see below) using the current values for circulating supply and block reward, then I suggest that the monitoring committee track how these numbers evolve over time.

---

• The minimum miner size required to be eligible for winning blocks is 10 TiB of raw byte power (RBP).

• How long does it take a new miner to reach 10 TiB of RBP?
  Let's assume it takes n days, with the miner adding 10/n TiB per day.
  (For example, if n = 30, that would mean the miner onboards ~10 32GiB-sectors daily over a month.)

• How much in fees is accumulated over those n days?
  Let F be the fee per TiB of RBP. The total fees accumulated by the end of n days is: F * 10/n + 2F * 10/n + 3F * 10/n + ... + nF * 10/n. Which simplifies to: F * 10/n * (1 + 2 + ... + n) = F * 10/n * (n(n + 1)/2) = F * 5 * (n + 1)

• Example: If n = 30 and the circulating supply is 680M, then: Total fees = 0.0012 * 5 * 31 = 0.186 FIL. This is the amount that the SPs has to add in the available balance to exit the debt situation. Note that, with the current 24H reward of 0.0036 FIL/TiB, that amount is repaid in ~ 52 days (if the miner stop growing/adding deals).

@beck-8 what a realistic estimate for n (the number of days needed to get from 0 to 10TiB RBP)? is a month too long or too short? Thanks

[beck-8]

Too long.
This may not be calculated here. It should be like this:

Notes:
The new SP should store a certain amount in the miner available balance, and the amount is used to pay dailyfee (because there may not be any blocks generated a few days ago)
If a user encapsulates a 1P sector, a fee of 0.128043599857 FIL is deducted every day. Users need to store so much in the Miner available balance to support the fees in the next few days.
Here, it is just a reminder to prevent some situations from causing the Miner to be 0 and cannot continue to encapsulate and block out. Pre-staking during the PCD stage will also be returned to the available balance of Miner, so there is no need to worry too much. But you must be clear about the following facts.
Nodes have the right to generate blocks after 10TiB, but nodes may only generate blocks after 1PiB or even after 2PiB. During this period, you need to pay attention to the deduction situation and do not let the available balance of Miner become negative.

[ipfsforcezuofu]

Could you please elaborate further on the 30% reduction in gas units? To calculate the current onboarding cost, one sector from SP f02865213 was randomly selected as a sample.

The messages for PC2 and C2 are as follows:
PreCommitSectorBatch2: bafy2bzacebkmxnptd6zccuqpjg6sibwjcs6eonyjkfyejjkgutstojlpkm5bc
ProveCommitSectors3: bafy2bzaceb4jxiipf3vli6otlopcsigedssmlbjjlphu3u7ndvbrqmkhcrdoa

From the messages, we can observe:
Basefee: 464 attoFIL
ProveCommitSectors3: 0.00045 FIL
PreCommitSectorBatch2: 0.00008 FIL
WindowPoSt for 540 days: 0.000009288 FIL
The total cost for this sector is 0.00054 FIL, which is 1/5 of the 0.0028 FIL mentioned in the discussion for the new proposal. Did I miss anything in this calculation?

[irenegia]

Hi @ipfsforcezuofu !

The 30% reduction refers to the number of gas units (not gas fees!) required to onboard a sector when using batching for pre-commit and proof aggregation for prove-commit. Let me walk you through this:

For simplicity, let's consider pre-commit (PreCommitSectorBatch2):

(Pre-FIP) With the batch balancer mechanism in place:

• It is not rational to use batching (i.e., sending one message for many sectors). Why?
  If an SP uses batching, they must pay the batch fee. In periods without network congestion, this fee is quite high—about 0.0041 FIL per sector in the batch.
• As a result, miners typically send 1 message per sector, leading to the following gas usage per sector:
  • In the case of your message: ~48.5M gas units per sector
  • In the message linked in the FIP: ~16.7M gas units per sector (this is from a much smaller miner, where cheaper storage accounting reduces costs)

(Post-FIP) Batch balancer mechanism is removed:

• It becomes rational to always use batching since there’s no batch fee anymore. We expect to see only PreCommitSectorBatch2 messages for 2 or more sectors (we'll request changes to Lotus miner configs to reflect this).
• This means 1 message can cover multiple sectors, significantly reducing the gas per sector, especially for storage-related gas. Now, the gas used per sector is simply: gasUsed ÷ sectors_in_batch
  • To estimate the savings, you can run a PreCommitSectorBatch2 for 2+ sectors and calculate gasUsed ÷ sectors_in_batch (note: you'll still pay the batch fee if you try this now).
  • We did this and send a message from the same miner with 4 sectors, using ~18.6 million gas in total (link in the FIP). Dividing by 4 gives ~4.6M gas units per sector—that’s a 3.6x reduction compared to the pre-FIP scenario.

The same logic applies to prove-commit (ProveCommitSectorBatch3) and NI-PoRep. Just note that you'll now need to compare single-sector messages with batched messages that also use proof aggregation to maximize gas savings. If you need more details, I’m happy to go over this in a follow-up message.

---

About Gas Fees:

• Gas fee is computed as gasUsed × baseFee. While gasUsed remains constant, the baseFee fluctuates over time.
• In the messages you linked, the gas fee was low because the current base fee is low.
• Imagine sending the same messages in December 2024, when the base fee spiked to 0.1 nanoFIL! You would have paid:
  • ProveCommitSector3: 0.028 FIL
  • PreCommitSectorBatch2: 0.00485 FIL

For context, ProveCommit gas alone (without considering any miner tip) would have cost 10x more than the entire per-sector fee for 540 days (~0.00275 FIL).

---

The Big Picture:
The goal is to move from the current system—where maintaining an onboarding rate close to 3 PiB/day requires paying either high batch fees or high base gas fees—to a system where we can sustain 3 PiB/day with ow gas fees (like today) and a easy to predict and constant over time per-sector fee.

[ipfsforcezuofu]

@irenegia
Thank you for your detailed explanation. To further compare the costs, I downloaded the basefee data from Jan 14,2025 to Feb 11,2025 and calculated an average basefee of 0.00054 nanoFIL, which is significantly lower than the 0.1 nanoFIL observed during peak times.

Based on this average value and the assumption of a per-sector fee for 540 days (~0.00275 FIL), could you suggest the optimal number of sectors to include in a batch to achieve cost equivalence before and after the FIP, or to realize a 30% cost savings?

[irenegia]

I downloaded the basefee data from Jan 14,2025 to Feb 11,2025 and calculated an average basefee of 0.00054 nanoFIL, which is significantly lower than the 0.1 nanoFIL observed during peak times.

Yes, January and beginning of February was a particularly "calm" period.

But if you the look at last couple of weeks activity, this is starting to look like end of last year again, meaning we could other spikes soon. In fact, we have already seen a couple of spikes in the past week:

[irenegia]

could you suggest the optimal number of sectors to include in a batch to achieve cost equivalence before and after the FIP, or to realize a 30% cost savings?

This is a difficult question to answer because it depends on many factors, including base fee fluctuations, miner size, hardware, and the sealing pipeline. I can't provide an exact number with confidence, but here’s what I can say about achieving the *30% savings *(or more):

• PreCommit: From the messages we analyzed, approximately 60% of the gas used in precommit is state-storage gas—this is the portion that can be reduced through batching. However, this percentage varies depending on miner size. Larger miners may see a higher proportion of state-storage gas (our analysis focused mainly on smaller miners). For medium-to-large miners, my guess is that batching 4 sectors should already result in about 30% gas savings for precommit. In general, the more sectors included in a batch, the greater the savings—although at some point (ie, with very large batches) the marginal benefit decreases as batch size increases.

• ProveCommit: Assuming we are dealing with sectors with f05 deals, the situation is similar to above. So to amortise state-storage gas, try at least 4 sectors. If possible, you should try more¹! The extra thing here (provecommit) is that you can have additional savings by reducing the computation gas part too by using proof aggregation²,. Note that in this case there is a max of number of sectors that can be included in an aggregated proof (819).

  • Also, it is worth noting that with NI_PoRep (use ProveCommitSectorsNI in the place of PCS3) one can save same savings from batching/aggregation and also save all precommit gas.

Footnotes

1. You can use batching for prove commit (with not proof aggregation) already now without having to pay the batch balancer fee. ↩

2. In practice, aggregation is currently giving less gas saving respect to batching due to a bug causing single proofs to be charged an incorrect amount of gas units. So currently, batching is to be preferred with respect to aggregation. Once this code bug is fixed, batching will cost more gas units and aggregation would be the option with the largest gas unit saving per sector. ↩

[Stebalien]

Fee Predictability

Concerns around fee predictability before sealing a sector were brought up in an out of band discussion. Specifically, the concern is:

1. SP sends the message to commit a sector.
2. Some shock happens with the circulating supply.
3. Sector gets a larger-than-expected fee.

Our proposed solution is to:

1. Use the average circulating supply over some period (1-2 days? longer?).
2. Use the average from a day (or more?) ago when calculating fees instead of using the current value. This value will be recorded in the reward actor ahead of time to give SPs a heads up as fees change over time.

Implementation wise, I'd prefer to record the fee directly in terms of per-byte power instead of just recording the circulating supply. This makes the fee trivial to understand. It also makes it easier for future FIPs to potentially change how this fee is calculated (if we find problems with the current method, find better methods, etc.).

[rvagg]

One concern we discussed today with having a daily value is needing to avoid time-based onboarding decisions during the day. Ideally we'd want to avoid having a time of day that is more optimal to onboard, or pause onboarding—it would be an unfortunate outcome of this FIP if we introduced a daily wave pattern in onboarding rate which itself puts downward pressure on total onboarding rate by having peaks that are closer to the gas limit.

Consider the proposal:

• Accumulate a running total of CS per epoch during each 24h period
• Capture the previous 24h average at the same point in time each day
• Use the previous day's CS value as the basis for the fee for any new sector
  • Offset that by some number of hours, perhaps 12h, so that you have an "announcement" period that the fee is going to change

How might this impact SP onboarding decisions as CS fluctuates from day to day? Are we at risk of having onboarding paused to wait for better fee conditions if the announcement shows a significantly lower fee if you wait? Or the opposite: the new fee is going to be significantly more so you bring forward any possible onboarding.

I don't think we imagine CS to vary all that much day to day, so maybe this isn't a big deal? I'm having a hard time imagining that this is not going lean us toward a more lumpy onboarding rate during any 24h period.

Maybe it would be best to just keep the last 2880 CS values in a vector (ring-buffer style) and use this to calculate the previous 24h average whenever you onboard a sector. Or alternatively, just use an EMA to update a single value each epoch and use that.

[rvagg]

@irenegia pointed out that Initial Pledge uses the point-in-time circulating supply value, so doing any smoothing is going to make it inconsistent. Either we do smoothing for IP as well or we just keep it simple and take it point-in-time. I'm going to update the FIP text for now to pull out mention of the power actor and suggest (@irenegia is suggesting this too) that if we need smoothing that we do it later and do it for IP too via a new FIP and maybe even do the calculation in cron as well as per #777.

[Stebalien]

Burn on termination

We've discussed burning up-front and burning over time, but we haven't yet discussed burning on termination and only on termination. The idea is:

1. In every sector, record the fee that should be charged for that sector per epoch. This fee will be limited up-front based on the projected rewards for the sector.
2. When the sector is terminated, burn fee*(termination_epoch - activation_epoch) from the pledge before returning it.

The upsides to this approach are:

1. Simplified implementation. We still need to add some information to each sector's state on-chain, but we don't need to do any per-epoch accounting.
2. Payment is simple: it's deducted from the pledge on termination (and guaranteed to never exceed the pledge). There's no need to top up, no way to go into debt, etc.

The downsides are:

1. Fees will accumulate but there won't be any visible burn of said fees until sectors start expiring.
2. Calculating termination "fees" becomes slightly more complex and this somewhat goes against the effort to simplify fees on termination. However, (a) this isn't a termination-fee, just a fee charged out of the pledge on termination, (b) the calculation is very straight forward, and (c) the maximum fee is very easy to predict.

[irenegia]

• Fees will accumulate but there won't be any visible burn of said fees until sectors start expiring.

  I am not concerned about this. The effect of this burn will anyway be in practice visible only after some time.

• Calculating termination "fees" becomes slightly more complex and this somewhat goes against the effort to simplify fees on termination. However, (a) this isn't a termination-fee, just a fee charged out of the pledge on termination, (b) the calculation is very straight forward, and (c) the maximum fee is very easy to predict.

  I am a bit concerned about this, we may want to check with authors of https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md before moving forward with this (if we do so)

• My main concern about burning the entire sector fee (ie, dailyPayment x sectorDurationDays) at termination is how to cap the fee to be 50% of BR. If we take the dailyBR at expiration or at onboarding time, this is not a good estimate for the dailyBR values in all the other days the sector was around.

[Stebalien]

this is not a good estimate for the dailyBR values in all the other days the sector was around

Personally, I'd use the initial daily estimate to make the fee predictable: the fee recorded in the sector info would be the capped fee. I agree it's not a great cap, but that cap was considered "acceptable" IIRC in the initial proposal.

[irenegia]

Edit on my prev comment: from the modelling pov charging at termination is not good. Waiting 1+ years to see the effect of this fee on CS is not aligned with fee design principles. cc @AxCortesCubero and @molly

[ax]

Wrong handle guys.

[Stebalien]

Edit on my prev comment: from the modelling pov charging at termination is not good. Waiting 1+ years to see the effect of this fee on CS is not aligned with fee design principles

That was my main concern:

1. With the daily fee, we:
   1. Reduce CS with the initial locked pledge.
   2. Reduce the rate at which CS rises by continuously burning from the rewards.
   3. Finally increase the CS when the pledge unlocks.
2. With the "fee at the end" approach, we:
   1. Reduce CS with the initial locked pledge (same as above).
   2. Keep adding to CS at the same rate as rewards unlock (same as today).
   3. Finally, increase the CS by a lower amount when the pledge unlocks.

So it shifts the effect into the future.

[Stebalien]

Paying in WindowedPoSt versus at deadline end

Some of the implementers prototyping this FIP discussed when to pay the fee: when the WindowedPoSt message is submitted or in cron at the end of every deadline.

Based on #1105 (comment), it seems like we need to do something in cron: we need to pay for unproven partitions.

Our realization was that, if we have to do that anyways, we might as well:

1. Record the fee as a single value in the deadline state instead of recording a per-partition fee.
2. Charge the per-deadline fee once at the end of the deadline, instead of paying each time a WindowedPoSt is submitted, then possibly paying again at the end of the deadline.

The only downside here is that we'll need to record the aggregate power in the deadline (which we don't currently do) in order to apply the %BR limit to the fee, but that's not a huge deal. Also, if we do this in cron, we won't need to call out to the power/reward actor because cron feeds all the necessary information into the miner actor directly.

The only added cost here is that non-faulting miner actor will perform a slightly more expensive cron operation as it will need to send some funds to the burnt funds actor, but we don't expect that'll be a significant burden (we don't need to invoke the burnt funds actor, just move some funds around).

The impact on the end user is:

1. No extra WindowedPoSt gas.
2. The fee cap applies on a per-deadline basis instead of on a per-partition basis.
3. Deadline objects become slightly larger.
4. Individual partition objects stay the same size as they are right now.
5. The fee is paid in cron so you can't simply trace your windowed post message to see what fees are paid. On the other hand, you really need to trace cron anyways if you want to catch all fees, so this doesn't really change the status quo.

[irenegia]

Thanks @Stebalien!

I have discussed this with @rvagg as well and I think the "pay at the of deadline in cron " is actually a good design choice that allows us to avoid the edges case of skipped windowPoSt. I'll updated the fip description to reflect this.

About:

The fee is paid in cron so you can't simply trace your windowed post message to see what fees are paid. On the other hand, you really need to trace cron anyways if you want to catch all fees, so this doesn't really change the status quo.

For tracing the fee we still have the per-sector values in the onchainSectorInfo structure, that may be sufficient for now (in future more work on how to properly trace cron messages. may be necessary anyway?)

[Stebalien]

For tracing the fee we still have the per-sector values in the onchainSectorInfo structure, that may be sufficient for now (in future more work on how to properly trace cron messages. may be necessary anyway?)

Ish. Even better, we have the per-deadline value recorded in the state.

The main issue is the cap: you can look at the state to see the max you will pay, but if we happen to hit the cap, it'll be incorrect (although I don't think that's likely to be an issue).

[momack2]

Moving question on the FIP predictions from @herrehesse here:

What are the cost and gas implications for an average miner sealing 100TiB daily under the proposed per-sector fee model compared to the current Batch Balancer?

[irenegia]

As @momack2 wrote, giving a good estimate requires assumptions on the network growth rate.
As an example, we can consider a network trajectory where for the next few months ~2.5/3PiB of data are added daily. In this case:

• Without this FIP:

  • If no batching/proof aggregation is used, base fee will spike to the range of ~0.1nanoFIL causing 100TiB of data to cost ~167FIL for onboarding gas fees (here I am considering an average of 552M gas units per sector for precommit, provecommit and PSD methods).
  • If batching at precommit and proof aggregation at provecommit are used, base fee will stay low (~100attoFIL), so gas fees will be ~0.0001FIL (here considering an average if 347M gas units per sector for precommit, provecommit and PSD methods). However, the batch fee must be paid in this case. Using the values for batch balancer in the code, we can estimate this cost to be ~52.6 FIL for 100TiB.

• With this FIP: Batching and proof aggregation can be used without having to pay any batch fee, therefore base fee will stay low and gas fees will be again ~0.0001FIL. The main cost will be the new per sector fee, which for 100TiB of data is:

  • ~0.016FIL for each day (==> ~8.8FIL in 540 days, assuming the current value of Circulating Supply) for a CC or deal sector (no datacap);
  • ~0.16FIL for each day (==> ~88FIL in 540 days) for a FIL+ deal sector (with datacap).

[herrehesse]

@irenegia The proposal indicates a 2% burn on the collateral for 1.5 years and a 4% burn for the 3-year sector duration. Will this be paid upfront as a burn?

[irenegia]

The proposal indicates a 2% burn on the collateral for 1.5 years and a 4% burn for the 3-year sector duration

No, this is not the right way to read the graphs in the FIP
The graphs show the impact of the fee only for sectors of 1.5y duration, the x axis is the time of when the impact will happen.
That is: in 2025 the fee/pledge ratio is 2%, in 2026 will go up to ~3%, in 2027 will go up to ~5% and so on.

Sorry if the description is confusing, we will update it soon !
In the meantime, more details can be found in the appendix.
cc @kkarrancsu

[irenegia]

Will this be paid upfront as a burn?

No, no payment is done upfront. The value dailyFee is computed once at provecommit time for each sector and stored in the sector info. Then, at the end of each windowPoSt deadline, a cap is applied to the dailyFee value (this is a security measure to avoid the fee to spike over a fixed ration of the per sector block reward) to compute the dailyPayment, which is then burnt.

So in short, compute the value once at precommit time for cost predictability but pay it over time (ie, daily).

[herrehesse]

@irenegia thanks for your explainer! All clear.

[momack2]

One conversation that's been ongoing while evaluating implementation options + tradeoffs is when to charge and account for the new per-sector fee: 1) upfront 2) daily over time or 3) at termination. This FIP proposes option 2) daily over time for a few reasons:

• Paying the fee up front can be prohibitive and slow down network onboarding due to requiring more up-front FIL collateral & leasing.
• Paying at the end (at an unknown termination epoch) is also prohibitive because SPs will likely spend or account for collateral & rewards already, and might see the one-time end-of-sector fee as a prohibitive cost.
• Day to day is an easy business level thing to do, because it can be offset by daily rewards the network is delivering over-time, which avoids any additional overhead or bottlenecks in the system due to a one-off fee.

The design of the fee was specifically constructed around daily accounting to minimize overhead and allow for increased network value accrual without bottlenecks on SP operations. Our focus is finding a viable implementation pathway to achieve this design.

[BigLep]

I'll add the notes I have on this topic from listening to conversations. Should we add more of this thread to the "Design Rationale" section beyond what is there about "Upfront Payment vs. Ongoing Payment"?

Upfront

• Pros
  • Simpler implementation
  • No ambiguity about the size of the fee since it happens right away
• Cons
  • No way to have dynamic cap applied. Doesn’t support a fee based on changing network state like circulating supply
  • Need to have enough funds to cover pledge (i.e., requiring more up-front FIL collateral & leasing)
    • Particularly problematic if you’re a new miner and don’t have the balance available
  • Early termination is more complicated because you’ve already paid

Daily

• Pros
  • No extra upfront costs. It is offset by daily rewards. Should be an easy business level thing to do, because it comes out of the rewards the network is delivering.
  • Early termination is straightforward for SPs; SP hasn't paid more than the days the sector was active.
• Cons
  • Higher implementation complexity
  • Less visibility for the miner because fee is spread
  • Causes some blurring of "is this a service fee" or "is this a onboard fee" (that happens to be paid while sector is active).

After the fact

• Deduct from pledge as discussed in Reduce onboarding gas & align value accrual by removing batch balancer and replacing it with a per-sector fee #1105 (comment)
• Pros
  • Straight forward implementation
• Cons:
  • Undoes some of the FIP-0098 termination simplification
  • No way to have dynamic cap applied
  • Burn happens X months down the road (shifting the effect as discussed here)

[BigLep]

🧵 Thread for API/interaction questions/requirements

1. I assume at the minimum that SectorOnChainInfo.daily_fee will be exposed in calls like https://lotus.filecoin.io/reference/lotus/state/#statesectorgetinfo (and in Forest/Venus equivalents)

2. I assume users will want an API for getting the set of fees for a given miner. For example, for this miner actor, return the <partitionNumber,feeAmount> tuples? Should https://lotus.filecoin.io/reference/lotus/state/#stateminerdeadlines be updated?

3. How will smart contracts want to interact with this "onboarding fee"? At the sector or miner level?

   • ☝️ is important to get input on

[rvagg]

1. At the moment lotus uses the raw SectorOnChainInfo as a return type for the StateSectorGetInfo API endpoint. I propose that we just update this to include the new form that we're introducing that has a DailyFee abi.TokenAmount field at the bottom of it, and this would show up for all sectors, including historic ones, where the fee is 0.

2. We're fortunate because StateMinerDeadlines returns a custom type that we can easily extend, we'll just add a new field to it and populate it from the deadline info we get from state:

type Deadline struct {
	PostSubmissions      bitfield.BitField
	DisputableProofCount uint64
	DailyFee             abi.TokenAmount
}

3. Is an open question. I'm not sure if @Schwartz10 might have thoughts on accessibility of fee information to smart contracts? At the moment we're not accounting for exposing anything and we need to budget for that work if it's going to be important to get fee information for a miner or sector, or some other variation.

[BigLep]

@Schwartz10 : we are closing out details for this. We know this touches FIP-0098. Is there anything we should do to support smart contracts (e.g., do you want a call that gives you the max fee for a given sector)?

[Stebalien]

Possible methods we can expose:

1. TerminationPenaltyForSector(SectorNumber): returns the exact termination penalty for that sector at this point in time.
2. MaxTerminationPenaltyForSector(SectorNumber): returns the maximum termination penalty for that sector at this point in time, not taking the daily expected rewards into account. This will cost less gas.
3. TerminationPenaltiesForSectors([]SectorNumber): returns the exact termination penalty for a set of sectors. Batching will save a significant amount of gas in case this is being called on-chain.

[BigLep]

Given there wasn't more input here on how to expose this, no work is planned for nv25. Node RPC APIs can be updated whenever, but changes to builtin-actors/ref-fvm will need to come with the next code-deploying network upgrade after nv25 (currently nv26).

[BigLep]

Miscellaneous clarifications for the FIP

Below are items I've heard raised or discussed, but I didn't see in the FIP the last time I looked (and the PR for marking it as "Draft" is merged so I'm avoiding commenting there.). I'm putting them down as potential amendments to make:

1. Make a callout about the effect of snap sector (no effect right?). We cover other sector mutations, and may want this for completeness.
2. Make clear that the fee is not proportional to power of the sector (i.e., all sectors at a given epoch will have the same daily_fee, regardless of sector size or storing data)
3. Given fee payments will happen in each Deadline and the cap calculation will use Deadline.live_power (reference), this means pre-FIP-0100 sectors will affect the cap.

[irenegia]

Make a callout about the effect of snap sector (no effect right?). We cover other sector mutations, and may want this for completeness.

That is covered by the following paragraph in the FIP: "If a sector is extended or updated, the dailyFee value is not changed but the cap will be computed considering the updated value of expected_day_reward (and therefore the dailyPayment is updated). The sector will keep paying dailyPayment for the extended duration."
"Snapping a sector" in the code is called "updating a sector" (the method for snap is called ProveReplicaUpdates

(But we will make that more explicit!)

[BigLep]

FYI that I started a PR for making amendments when I spotted a couple more: #1124 . Feel free to close if this isn't the right process or if authors had other ideas in mind.

[rvagg]

👍 this is good, we're working through details at the moment and things may change as we get our hands increasingly dirty.

[momack2]

Flag that we've identified a slight delta per the clarifications here after discussing with @kkarrancsu about how modeling was configured:

• yes, the fee is proportional to the power of the sector (all the graphs and models have been done showing proportionality to initial pledge (IP) and BR, which are also proportional to sector power). The fee rate is set per 32 GiB QA Power (and should be scaled appropriately). We'll clarify that in the FIP to be super explicit!
• given that - there will be a change at sector snap because the sector power changes at that time. I believe other mutations are correct (ex extension) but will audit.

[momack2]

I think that folks have been modeling this into their evaluation already - but wanted to clarify that the per-sector fee specified in the FIP (https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0100.md#per-sector-fee-added) is defined for a 32 GiB QAP sector (and adjusts proportionally to power). This is consistent with how all the included graphs, simulations, and comparisons vs a BR or IP-based fee design were calculated. 👍

[irenegia]

Update for this week:

1. After further discussion about, we decided to update the formula for dailyFee to align with the model used to create the graphs here by incorporating its dependency on QAP. See FIP 0100 clarifications during last call #1124.

   • Note that this means that the specific fee values we provided in this discussion, for example see in my previous message here, have been updated accordingly (ie, 10x for fil+ deal sectors). Please @herrehesse review the edits there, thanks!

2. In the same PR, details clarifying the fee implications for sector extensions and sector updates (aka snaps) were also added. In particular,

   • Sectors onboarded before FIP-0100 is deployed and later updated or extended will start paying the fee after the extension/update (they will pay in the same way as newly onboarded sectors);
   • For sector already paying the fee, updates and extensions cause the daily fee value to be updated depending on the new sector quality adjusted power.

[Stebalien]

Sectors onboarded before FIP-0100 is deployed and later updated or extended will start paying the fee after the extension/update (they will pay in the same way as newly onboarded sectors);

IMO, this makes sense for extended sectors. However, I'm concerned about doing this for replica updates as I really want to encourage replica updates (i.e., encourage the use of existing capacity to store user data).

[LendMi]

It is beneficial to newly joined SPs. It is harmful to old SPs.
This will push old SPs to choose sector expiration and repackaging between sector renewal and sector expiration.
However, there is an uncertainty in this process.
Not all expired SPs will be repackaged. So there is a possibility of losing SPs.

[rvagg]

@LendMi can you explain this a bit more, I don't think I'm following your point. Current sectors for existing SPs will have a zero fee value for the rest of their current term, which should be beneficial compared to new entrants. It's only when extending of snapping that a fee gets added, and there would be a window of time between acceptance of this FIP and its activation on mainnet where sectors that are due to expire soon can be extended and lock in that zero fee state for additional time.

[gitgavinzhao]

Why should SP be forced to accept the early renewal plan in terms of operational strategy? Can FF handle the potential risks that may arise?

[rvagg]

Separate to the fee mechanism, this is a thread for a proposed change in #1133 for adjusting the calibration network circulating supply so that it closely matches mainnet. The summary of the proposed change is:

1. Original FIP-0100 proposal was to make circulating supply more accurate by reflecting the actual initial mining reserve amount of 900M FIL (it's the fact that this value is so far from the 300M on mainnet that's causing problems). This gives us a circulating supply today of ~380M FIL on calibration net.
2. Proposal is to artificially boost it even more and pretend that the initial mining reserve was 1,200M FIL which would yield a current circulating supply of ~680M FIL on calibration net, very close to mainnet, and giving us fee values that are almost identical.

So it's a choice between accuracy and having a test network that's more similar to the network that it's trying to emulate for testing purposes.

[Stebalien]

We could also change the actual circulating supply (it's a test network, the token value is 0).

[rvagg]

But I think that would involve messing with vesting or mined. Vesting seems tricky to mess around with, mined would mean tweaking what's in the reward actor TotalStoragePowerReward, which doesn't seem hard to do (in a migration), and then set InitialFilReserved correctly to 900M and we'd get the same outcome. It seems a bit simpler to me to just mess with the feed-in variables here than to mess around with state to simulate it. Unless you have another suggestion?

[Stebalien]

I'm thinking we just bump the value of some account then change the circulating supply appropriately.

[rvagg]

But the CS we care about is calculated using an estimation method rather than actual. We'd have to put it in some account but then also say it came from some other source that we count. Mined blocks, vesting, mining reserve. We could say the mining reserve started with then 900M it really did and then inflate further by taking 300M of that out into some other account. It would make it more accurate but is a bit more awkward because it needs the calibnet specific migration.

[Stebalien]

That's basically what I was suggesting but you're right, having a calibnet specific migration isn't worth it.

[dannyob]

A governance note: After the conversation with APAC SPs yesterday, a discussion with the folks planning nv25, and a (lightly attended) meeting of core devs today, there was agreement across all these groups to delay the end of Last Call for this FIP until Tuesday March 11, rather than have Last Call end on Friday March 7 as was originally scheduled. This gives an opportunity for further discussion and to consider changes to the FIP.

To that end, I'm picking out a couple of recurring themes in the discussion here. These are the key contentious points, to my mind:

• The new fee is too large relative to the current cost of onboarding.

• The fee is unfair to established SPs who paid gas fees to onboard originally, and will now have to pay additional, ongoing sector costs when these sectors are extended.

I think it may be useful to explore these two topics further.

A couple of other areas that I think have been resolved or I believe we won't be able to reach a new consensus on:

• @Fatman13 asks: Are high gas costs really an urgent problem?
  While not universal, SPs in the APAC meeting and elsewhere have said this is a problem; as an additional datapoint, I've also seen a post from an exchange that is having to delay FIL payments, often for some time because of gas fee spikes. It's also effectively capping onboarding rates as described above by @irenegia. I do think that these are the kind of active complaints from the SP community that we should act upon.

• Can we get rid of the batch balancer first, and then work out a new fee solution?
  In talking to some of the voices opposing the FIP as it is drafted now, there seems to be some agreement that swapping in a replacement fee in return for losing the batch balancer charges is still "fair", even if there's disagreement about whether the proposed fee structure is appropriate. I don't currently see a way to any consensus on what we would do if we just scrapped the batch balancer now, and then delayed the debate over novel fee structures to a later upgrade. So for the time being at least, we should consider this proposal as a whole.

[Fatman13]

A couple of other areas that I think have been resolved or I believe we won't be able to reach a new consensus on:

While not universal, SPs in the APAC meeting and elsewhere have said this is a problem; as an additional datapoint, I've also seen a post from an exchange that is having to delay FIL payments, often for some time because of gas fee spikes... I do think that these are the kind of active complaints from the SP community that we should act upon.

I believe we won't be able to reach consensus on burning mining reserve, but as additional datapoints everyone i talked to adamantly advocate the idea of burning mining reserve. Thus I do think that these are the kind of active supports from the miner community that we should act upon, ie including burning mining reserve into nv25.

[NDLABS-Leo]

Hi Community!

We are not in favor of this FIP for the following reasons:

Regarding “The new fee is too large relative to the current cost of onboarding.”, we have conducted calculations based on last year’s data, which some partners' node and obtained the following specific results (if there are any discrepancies, we welcome feedback):

According to our calculations, the “removing batch balancer and replacing it with a per-sector fee” proposal would reduce the additional net rewards of SPs by approximately 3.2% - 4.09%. Moreover, this calculation is based on last year’s real gas consumption when the overall network Gas fees were higher than they are now. Under the current lower Gas fee environment, the revenue difference is expected to further expand to around 5%.

If this proposal is implemented, a 3.2% - 4.09%, or even up to 5% reduction in revenue could have a significant impact on SPs, potentially threatening their long-term viability. Such changes may lead to a considerable number of SPs exiting the network, which would be detrimental to the stability and long-term growth of the Filecoin ecosystem.

Additionally, another key point is the loss of flexibility in SPs’ sealing strategy. Under the current Gas fee model, SPs can strategically choose to seal data when Gas prices are lower, optimizing their costs. However, with the new proposal enforcing a fixed per-sector fee, SPs would lose this flexibility, potentially increasing their operational cost burden.

In summary, we hope the Filecoin community carefully evaluates the impact of this proposal on the SP ecosystem and network health, and considers a more flexible and sustainable optimization plan.

[irenegia]

Thanks, @NDLABS-Leo, for the detailed post!

Regarding:

(if there are any discrepancies, we welcome feedback)

The math looks good to me, and the range you calculated (ie, 3.2% - 4.09%) is fairly close to what is reported in the FIP-100 appendix (ie, ~2x ROI reduction over the next year). There are just two points that might explain the slight divergence between the two calculations:

• ROI Calculation Methodology: We compute ROI reduction as (reward - fees) / pledge, whereas (if I’m not mistaken) your model does not account for the pledge.
• Gas Burn & Base Fee Impact: The 30% reduction applies to gas units, meaning that with less gas burned, the base fee will be lower than last year (assuming the onboarding rate stays below ~5 PiB/day).
  This results in additional cost savings, which we incorporated into our model by considering lower gas fees for the "medium" and "high" cases compared to the scenario you analyzed here.

[gitgavinzhao]

It is inappropriate to attribute the low onboarding rate to the gas problem. If FIL+ cannot increase QAP,
The 30% saving on gas obviously cannot drive QAP. Compared with the first significant reduction in GAS, referring to the coin price at that time and the current coin price and the FIL+ bonus, the reason for the low onboarding rate should be other reasons rather than gas, perhaps due to the reduced enthusiasm for Filecoin and pessimism about the future.
Paid storage target? Governance reform? Or something else?

[dannyob]

So all of these are definitely ways to increase confidence and onboarding rates (and I'm going to ping you separately about governance reform to see if we can accelerate that in particular).

The issue as I understand it, isn't a low onboarding rate -- SPs are trying to onboard more data than the network currently is allowing them to do so at a low price.

Because the onboarding cost is currently charged in units of gas, when more SPs onboard, the network gas usage increases, gas prices increase, and onboarding gets costlier, so SPs stop onboarding. That's putting an artificial limit on how much data is onboarded of about 3-4PiB. The high gas fees show that SPs are trying to onboard more data, they're just being unfairly penalized for it. See @irenegia's original post here.

[gitgavinzhao]

From deepseek for reference, Small SPs and new SPs should face the same operational difficulties. While solving the gas problem, introducing usage fees is a solution that complicates the problem and does not focus on the goal.

Gas issues are an important challenge in the Filecoin network, but they are not the primary reason for the low onboarding rate. Gas issues primarily affect transaction costs and network efficiency, while the low onboarding rate is more influenced by a combination of economic, technical, ecological, and competitive factors. However, Gas issues do exacerbate the low onboarding rate to some extent. Below is a detailed analysis:

Impact of Gas Issues on Filecoin
High Transaction Costs:

Gas fees are the computational resource costs required to execute transactions (e.g., storage deals, proof submissions) on the Filecoin network.

When the network is congested, Gas fees can increase significantly, raising the operational costs for storage providers.

Network Congestion:

When a large number of transactions occur simultaneously, the network can become congested, further driving up Gas fees.

This affects the efficiency and profitability of storage providers.

Impact on Small-Scale Storage Providers:

High Gas fees have a greater impact on small-scale storage providers, as they may not be able to分摊 costs as effectively as larger providers.

This may make it difficult for small-scale participants to remain profitable, leading them to exit the network.

Relationship Between Gas Issues and Onboarding Rate
Although Gas issues increase the operational costs for storage providers, they are not the root cause of the low onboarding rate. The main reasons for the low onboarding rate include:

High Initial Costs and Capital Requirements (hardware, FIL collateral, etc.).

Technical Complexity and Resource-Intensive Processes (sealing, proving, etc.).

Uncertain Economic Returns (FIL price volatility, slashing risks, etc.).

Intense Competition and Economies of Scale (dominance of large providers).

Lack of Support for Small-Scale Participants.

Gas issues exacerbate these existing problems rather than directly causing the low onboarding rate.

How Gas Issues Indirectly Affect Onboarding Rate
Increased Operational Costs:

High Gas fees increase the daily operational costs for storage providers, reducing their profitability.

This may deter potential participants from joining the network.

Reduced Network Efficiency:

Network congestion and high Gas fees can lead to transaction delays, affecting the efficiency of storage providers.

This may cause new participants to question the reliability and user experience of the network.

Unfriendly to Small-Scale Participants:

Gas fees have a greater impact on small-scale storage providers, as they may not be able to分摊 costs as effectively as larger providers.

This further exacerbates the competitive disadvantage of small-scale participants.

Potential Solutions to Gas Issues
Optimize Network Performance:

Improve network throughput through technical upgrades (e.g., sharding, Layer 2 solutions) to reduce congestion.

Optimize the Gas fee calculation model to make it fairer and more predictable.

Introduce Gas Fee Subsidies:

Provide Gas fee subsidies for new storage providers to lower their initial operational costs.

Design incentive mechanisms to encourage efficient use of network resources.

Improve Transaction Prioritization Mechanisms:

Set different Gas fee priorities based on transaction types (e.g., storage deals vs. regular transfers).

Ensure critical transactions (e.g., proof submissions) are prioritized.

Raise Community Awareness:

Educate storage providers on how to optimize Gas fee usage (e.g., submitting transactions during off-peak hours).

Provide tools and resources to help participants better manage Gas costs.

Conclusion
Gas issues are an important challenge in the Filecoin network, but they are not the primary reason for the low onboarding rate. The low onboarding rate is more influenced by high costs, technical complexity, uncertain economic returns, and intense competition. However, Gas issues do exacerbate these challenges, particularly for small-scale storage providers. By optimizing network performance, introducing subsidies, and improving transaction mechanisms, Filecoin can alleviate Gas issues to some extent, thereby indirectly improving the onboarding rate.

[dannyob]

Gavin, I'm not sure it's useful to just cut-and-paste in AI-created text into this discussion, especially when you're not including your prompt (feel free to put it the prompt and the resulting text elsewhere and link to it here). A lot of this LLM-generated text is somewhat inaccurate and irrelevant. It also seems to be assuming that the argument you're opposing is that gas fees are the reason onboarding is low, and they should be compared to other methods to increase onboarding.

In fact, the argument is that onboarding rates are already increasing, and gas fees are going up as a result because base rates of gas and onboarding rates are (incorrectly) tied together. The FIP is an attempt to break that connection. If we don't fix that connection, then all of these other ways to increase onboarding even more are just going to hit the effective (and unnecessary) limit for data onboarding that charging gas for onboarding causes. I think that's right. Whether it's right or not, do you understand my point here?

[gitgavinzhao]

I support lowering gas. Even if FF agrees to cancel gas, as an SP, I oppose the introduction of a usage fee. There is no high-sounding reason for this. The reason of loss of revenue is enough. As for whether this usage fee will affect the survival of SP, obviously no one can answer on behalf of SP.

[dannyob]

That seems right to me -- lowering gas fees is good for SP's bottom line, and a usage fee makes it worse. You're right that there doesn't need to be a high-sounding reason!

So, the question is: can we make this so that gas costs are stabilised, and the usage fee seems reasonable. We can't get rid of the fees entirely, because the cryptoeconomics depend on /some/ FIL being burned over time. I do understand the complaint that SPs have that this burning in particular comes at the cost of SPs. I definitely understand the suspicion that token-holders will always push for more burning, without taking into account the cost to SPs (though I will note the lack of enthusiasm for, say, burning the mining reserve seems to indicate that FIL holders aren't always gung-ho to eke out value by reducing the FIL supply.)

[algo-cpu]

Hello everyone, I am a new SP who joined in the past two years.
I am against this FIP because:

1. We renew in short periods to provide as much liquidity as possible and cannot renew for a long time at a time
2. I have many more packaging tasks in the future. On the basis of the original decline in revenue, I cannot convince my customers to continue packaging. I only charge 6% of the customer's coin production income.

suggestion:

1. Can the cost of newly packaged nodes be reduced?
2. Is it possible to renew the old nodes without being affected?

[dannyob]

Not the FIP authors, but thank you for the suggestions. This seems to be the thrust of many SP requests in this thread.

[Aaron0xG]

So consider our proposal: no additional fees will be charged for the maximum life cycle of old sectors within 5 years

[dannyob]

I want to make sure that all the points being made are included in this discussion, including ones made by ecosystem members who have been a little burned-out on long Github threads (I think we all know that feeling).

So, while I was talking to a (non-APAC) SP, he highlighted this text from FIP13:

Miner Fairness. Small, Medium, and Large miners must have proportional gas economics -- there should be no exploitative economy of scale that benefits larger miners disproportionately. Costs should remain balanced across strategies. The cost reduction should be a well-defined discount, and should be available to small miners.

He argued that FIP100 might change the balance between SPs with different strategies. Onboarding SPs would pay less, but those extending sectors would end up paying more. "this can and will only be beneficial for miners that grow significantly compared to the sector base they already have onboarded."

I don't know enough to agree or disagree, but I wanted to put the point into the conversation to see if it can be addressed.

[irenegia]

but those extending sectors would end up paying more

Let’s compare two scenarios:

• Old sector (540 days) extended for another 540 days: Total fee: gasFee1 + 540 * newFee
• New sector (3 years): Total fee: gasFee2 + 2 * 540 * newFee, where gasFee2 ≈ 30% of gasFee1 (or even lower).

From this rough back-of-the-envelope calculation, whether an extended sector pays more or less depends on: (1) Gas conditions at onboarding, and (2) Circulating supply at the time.
I think i t's not necessarily true that extended sectors always pay more. In fact, they might pay less because they didn’t have to pay the new sector fee in the past.

That said, I completely understand that introducing a new fee to ongoing sectors alters the economic equilibrium, and adjusting to it can be challenging!

[mjroddy]

It's probably worth noting that older sectors have earned higher FIL rewards in general too.

The rewards don't exactly stay the same.

[mjroddy]

Hi All I wanted to write something briefly to argue for supporting this FIP (even as an SP).

I note some of the concerns raised and will try address some of these.

This proposal is a net positive for the ecosystem. Removing the batch balancer simplifies the protocol and moving the protocol towards charging for services it is actually providing (in this case an audit service for the SP's) is more sustainable.

One of the major issues I see currently in the Filecoin economics is that there is little reason for people to hold the token. Today, burning FIL (deflationary forces) only occurs through 1) gas execution and 2) penalties when miners fault. Both of which we should be trying to minimize as much as possible. The issue is that if we successfully lower gas execution and reduce miners faulting, how is value accrued to FIL long term? it doesn't.

We have to start thinking about how Filecoin's economics are tied to it's value proposition. One clear value proposition is the audit service that Filecoin provides for SP's. SP's should be willing to pay for this. Arguing that it is too high relative to current onboarding rates imo is not the right way to be framing this. The question is whether the value provided by the blockchain for the audit service of the sectors is reasonable - I'd argue it is.

This proposal will have second order effects. i.e. having more deflationary forces should make the token more appealing to investors. Having more burn accrues value to the token and given that all SP's still earn majority of their income in FIL should be a MAJOR consideration. Just comparing net rewards or looking at the fee as just a 'tax' is the wrong framing. We need to create a sustainable economic framework and this fee I'd argue is the start of that. It's not to say it should be the only fee, we should be charging more fee's where it makes sense. It makes sense here.

I am empathetic that this type of fee may cause lending agreements to be changed going forward but this shouldn't be a reason to stop the proposal. We need to think longer term about what economic model we are building and not just opposing a FIP because it doesn't fit into a 3-6 month lending contract SP's have in place. Similarly, with regard to fee's on extended sectors, we shouldn't fall into a trap of not updating economics because 'this wasn't proposed when I signed up' type thinking. Longer term, having a per sector fee makes a lot of sense and is equitable against all SP's. I'm very open to transition periods etc. but we should very much stop short of having effectively two tiers of storage on the network (i.e. pre and post fee).

Further, as a network we shouldn't be afraid of SP's leaving the network if the economics don't work for them. I'm not suggesting this is a good thing but if our metric for not upgrading the economics of Filecoin is that we don't want any SP's to leave because of a proposal we will not make any progress in upgrading the network. I don't think it's controversial to say that our supply side is still much larger than the demand side.

In short, Filecoin will benefit much more from having sustainable economics longer term then a small increase in per sector fee. SP's specifically will benefit much more given that the large majority of their income is tied to FIL therefore having better economics should be in SP's best interest.

TLDR:
I'm very supportive of introducing an onboarding fee. SP's receive a service from Filecoin and should be willing to pay for it (Even if that means slightly less rewards). The fee would make the economics of Filecoin stronger and more attractive to investors which would be more beneficial to SP's in the first place.

[Aaron0xG]

PL said the purpose of the proposal is to unlock network growth, and you said we should not be afraid of SP's leaving the network, which is a contradiction in terms.

[mjroddy]

The proposal addresses batch balancer which is a bottleneck to onboarding.

Paying a fee for a service is not a bottleneck.

My argument is that IF a side effect of introducing the fee is that 'some' SP's leave then we shouldn't use that as an excuse to not make changes.

Basically we need to be more practical around the longevity of this project. If we don't start making sustainable economic decisions in a few years there won't be much of an incentive to join Filecoin anyway.

[algo-cpu]

Are you sure you are an SP? You may not even have a node and cannot even start the lotus service.

[mjroddy]

Helpful input.

Do you agree that making FIL attractive to token holders by introducing a fee (burn) is going to be beneficial to SP's who earn that same FIL?

[dannyob]

Let's be civil everyone: Mark works at Holon, which is indeed an SP. I can also say that at least one other SP has voiced their approval of the FIP (like the posted criticism of the FIP above, some folks are uncomfortable joining the discussion here, partly because it can get a little feisty, but I think it's useful to reflect on their input).

[Aaron0xG]

From the SP's perspective, I oppose this proposal for the following reasons:

Unfair Treatment of Existing Miners
The new proposal may indeed attract more new SPs, but it will also drive away existing miners who have contributed to the ecosystem. For them, it is unfair. When I initially sealed these sectors (e.g., f02101475, QAP 30P, cost 5K+ FIL on gas), we had already paid substantial GAS fees. Why should we pay additional GAS fees for these same sectors now? A more reasonable approach would be to exempt existing QAP from the extra costs imposed by the new proposal. The additional fees should only apply to newly sealed sectors.

Renewal Issues
The proposal states that there will be no additional GAS fees when renewing up to a certain time. However, many miners, like us, obtain pledged coins through partnerships with institutions. We need to renew every three or six months based on the contract rates to maintain better liquidity of pledged coins. If the proposal aims to waive GAS fees for existing sectors, it should do so for the entire sector lifecycle of five years, not just until the renewal height.

Impact on SP Yield
It is well known that the yield for SPs on the FIL network is already low. If this proposal does not exempt existing sectors from fees, it will artificially reduce SP yields (by approximately 15%). For some miners with poor cost control, they might even shut down and exit the network. This loss of computing power cannot be fully offset by the new computing power attracted by the proposal. Even if it could, it would come at the expense of existing sector revenues.

Conclusion
In summary, I believe this proposal lacks comprehensive consideration and fails to address the concerns of existing miners. Reducing the revenue of existing sectors may lead to their exit. The proposal needs to be re-evaluated to ensure fairness and sustainability for all participants in the ecosystem.

If the new proposal can exempt fees for up to 1.5 years, why can't it exempt fees for the full lifecycle of 5 years? I believe the latter would be more beneficial and fair to all existing sectors. The claim that "Plenty of time for the SP community and loan providers to adapt to network conditions" lacks supporting data. You need to conduct surveys or provide evidence to substantiate such a statement.

When I talk about better liquidity, I mean short-term multiple renewals. Miners can have more flexibility to exit or continue renewing their sectors rather than committing to a one-time renewal for 1.5 years or longer.

Let's take the example of the f02101475 node, which has 64G sectors. It contains 50,391 sectors, with a QAP of 30.53 PiB. According to the calculation:
For deal sectors totaling 100,000 FIL, an additional cost of 2800 FIL over 540 days is incurred.
image
For the same QAP with 32G sectors, the yield reduction would be 32.8%.


The block reward was 8.67 11 months ago, and the block reward today is 6.12. It has been declining in the past three years. Without considering the impact of the total network QAP, the approximate annual average block reward is: (8.67+6.12)/2 = 7.395. The annual average reward is the discount factor of the current block reward: 7.395/8.67 = 0.85, which is a relatively optimistic discount.

SP's profit is already very low, and the new proposal is more like an additional tax on old miners. Please do more questionnaires, pay attention to their living conditions, and consider the more reasonable plan we propose.

[mjroddy]

Quick question do you know if that miner in question charges any fiat for storing 3PiB of data?

[dannyob]

@Aaron0xG when you say "consider the more reasonable plan we propose", do you mean "no additional fees will be charged for the maximum life cycle of old sectors within 5 years"?

[Aaron0xG]

@Aaron0xG when you say "consider the more reasonable plan we propose", do you mean "no additional fees will be charged for the maximum life cycle of old sectors within 5 years"?

yes

[xiaoliwe]

Results: As a new SP, we oppose this proposal!
Here is reason:

• Our team has invested a significant amount of time and over hundreds of thousands of US dollars in the FIL project, and the block reward earnings to date still cannot cover the IDC costs.Under such circumstances, it is extremely unreasonable for the project team to still insist on promoting the new FIP proposal to increase the cost of SPs.
• The FIP-0100 proposal is to solve the batch balancer problem, but first we need to understand why it was not considered clearly or there were design flaws when it was first designed. It is a very bad proposal to solve this problem by increasing SP costs.

Thanks.

[gitgavinzhao]

The standard approach of PL: solve a small problem and introduce a big problem. The same is true for FIL+. Achieving 10 times the computing power, introducing a notary, a big problem. What about QAP and data quality? A lot of time and resources are wasted, and there is no progress in paid storage.

[dannyob]

So we're coming to the end of the Last Call process, and I'd like to summarize some of the objections here. I've reached out to the FIP authors and made some broad suggestions as to amendments based on this discussion, as well as direct conversations with concerned parties, and my own sense of what might be feasible within the terms of the proposed FIP itself.

The next step, because this is a spicey FIP, is for a meeting of coredevs in the next week, where we will see if we can get consensus to move forward, or reject this FIP.

The arguments for the FIP are that it helps alleviate the high onboarding gas costs right now, replacing them with a more consistent fee across the lifetime of the sector. Objectors to the FIP point to the unexpectedly high cost of this fee especially when considering QAP sectors, lowering ROI in an already uncertain economic environment for Filecoin SPs, and what they feel is the unfairness of a perceived shift in cost, especially for older SPs who already paid the high onboarding costs in the past.

There are also concerns that this FIP may have damaging effects on the ecosystem as a whole. It may accelerate SPs leaving the system because of the change in ROI. It may change the balance of incentives between different SP strategies. Any change to cryptoeconomics is potentially disruptive, and predicting the consequences is an inexact art. The ecosystem relies on the calculations of Filecoin's cryptoeconomists and protocol designers at FIlOz and CEL, and it can be hard to parse or challenge those from the outside, which lowers trust in those predictions and process.

As a result of the above, I ask the FIP authors to consider the following modifications to the existing proposal:

• Consider lowering the fee. Like others, I don't have all the expertise I need to understand how the fee level was determined, but from AMAs and direct conversations, my understanding is that the authors modeled several values. I feel that, from the point of view of many SPs, the final fee figure was higher than expected -- which is what led to such pushback in the final days of the FIP.

• Consider changes that would soften the blow for established SPs that have already spent gas onboarding data. This is a trickier ask, but there have been a few discussions of approaches from SPs in the discussion above that may be adopted without changing the fundamental principles of the FIP. SPs have noted that changed the length of time they extend sectors may be challenging with existing investor agreements. At the very least, it benefits the stability and confidence of storage providers to have time to adjust to new conditions.

I am also going to submit my own proposed change, which is more governance-related. I propose that coredevs commit to reviewing the impact of this FIP in the short-term, in time for subsequent releases nv26 and nv27 -- to see if the predictions of its critics and its proponents come true, and on the basis of those conditions, how to adjust, adapt or even if necessary roll-back the FIP's approach.

To assist them, I propose a small ad-hoc committee made up of both critics and supporters of the FIP, who will monitor ecosystem conditions, and supply them with recommendations. I have proposed to FF that it provide a small budget for independent research guided by the committee's members so that they can be informed of the facts on the ground, independent of those included by the FIP authors. The research could be conducted by the Cryptoeconomic Lab, independent protocol developers, or companies like Blockscience. This committee will not be expected to reach consensus, and its members can submit independent reports to coredevs.

I'll leave it to the FIP authors to give details of any changes they plan to make; once that's done, we'll close this FIP and pass it onto coredevs for consideration, hopefully in the next few days.

[momack2]

Over the past week, we have welcomed a number of new participants to the FIP discussion, and their involvement is greatly appreciated. This participation helps us better understand and address the concerns and requests from various network stakeholders, which form the basis of this FIP. The proposal aims to unblock sector onboarding from gas limits, such as the batch balancer, while maintaining and enhancing direct protocol value accrual via per-sector fees. All FIP participants generally support removing the batch balancer, unblocking network onboarding rates, and simplifying the predictability, implementation, and optimization of gas fees. However, we have observed some divergence within the SP community, with opinions ranging from full support of the FIP to concerns about potential impacts.

Thank you Danny for summarizing some of the concerns and proposing a path forward to some compromises. 🙏

The current proposed per-sector fee model already includes a number of compromises to find an efficiently implementable, modelable, and palatable solution across the goals stated in the FIP discussion and design. Based on the concrete feedback shared here, we plan to implement a number of additional compromises into this FIP to respond to the concerns raised by SPs from a few different backgrounds.

The actionable feedback we heard includes:

• Effect on SP Profitability: Some SPs are concerned about FIL ROI for new, extended, or upgraded sectors that incur the new fee. FIL ROI delta for the proposed fee construction is expected to start around ~2% of 1 year sector ROI, increasing or decreasing depending on network conditions to anywhere from 1-11% 1Y sector ROI over the next 10 years.
• Support for Existing SPs Business Operations: Existing SPs who have upcoming sector expiry are concerned about losing flexibility in short-term FIL loan contracts to collateral providers who want to maximize 3-6 month liquidity and avoid long-term sector extension. Existing loans might require shorter term extension windows that don’t allow them to take advantage of the 1.5 year sector extension limit in the short term.
• Concerns over Unintended Consequences of a New Fee Structure: There are concerns over the ability for simulations to correctly model and predict effects on network QAP, new miner participation, smaller miner ROI, or overall economic impact. Some SPs question the accuracy of the MechaFil simulations, initial conditions, and whether the fee will perform similarly to simulations in practice.

Based on this feedback, we’re making a set of changes to the proposed FIP to recognize and respond to these concerns:

1. Lowering the Fee: To mitigate shocks to SP profitability, we’re decreasing the fee constant from k1= 7.4 E-15 to k1 = 5.56 E-15. This new fee value is 25% lower than the previously proposed fee value, with the expected ROI delta range over 10 years lowered accordingly to between 0.5-8% of 1Y sector ROI (depending on network growth rates). See the differences in the last column in row 1 (new fee value) vs row 2 (old fee value) in the original FIP-100 appendix:
   

2. Extension Grace Period for Existing SPs: To support SPs with existing loans who require shorter-term flexibility, we’re creating a 3 month grace period during which existing sectors will be exempt from incurring this fee on extension. This will allow these SPs to adjust their loan arrangements to better take advantage of new discount opportunities, or adjust loan conditions to share this fee with their loan providers (as it’s been designed). Hopefully that gives more established SPs time to adjust to new conditions.

3. Governance-Led Monitoring Committee: Potential unintended consequences or different behavior than simulations are fair concerns - however our modeling capabilities are insufficient to collect stronger data on the potential performance of this fee without moving forward and observing real impacts in live network conditions. Arguing for many quarters about what might happen without real data will be ineffective, inefficient, and a bad use of developer time - ultimately hurting the improvement rate of Filecoin. We are very open to this fee not being the perfect construction on the first try, and requiring additional alterations based on observed network conditions and effects. Therefore, we are very onboard with Danny’s proposal to convene quarterly (every 3 months) review sessions with stakeholders across SPs, core devs, token holders, and storage clients - to evaluate the observed performance and response of this FIP and decide whether to a) revert it, b) amend it with a new FIP proposal, or c) continue monitoring its behavior. This will allow us to make faster and more informed decisions, and avoid wasting community resources arguing about what might happen without data.

As FIP authors, we believe that by adopting these mitigations to the concerns highlighted, it is reasonable to exit the current last call process and assess the impacts of this compromise FIP in real network conditions through inclusion in nv25 to gather data for explicit monitoring, evaluation, and potential amendment. Our aim is that by closely monitoring the real-world observable effects on SP onboarding, ROI, sector extension rates, QAP growth, new investment, new SPs, protocol revenue, and similar economic signals - we’ll be able to more effectively iterate on an appropriate per-sector structure that helps drive Filecoin to success. We will share this plan with Core Devs for alignment this week to proceed on the nv25 launch schedule. 🚀

Thank you to everyone who participated in this FIP discussion - and for all the actionable and helpful feedback to incorporate into this valuable experiment. We plan to closely monitor and report-back findings as we go here - and welcome your input into important metrics and data-points to monitor closely!

[xiaoliwe]

Looking forward to seeing more plans for the convene quarterly review sessions.

Thanks team.

[beck-8]

Thank you very much for the summary.
Hopefully all the relevant parameters linked to FIP100 can be updated.

[Destore2023]

Thank you to the @dannyob @momack2 team for listening to the voices of the SP community. It is hoped that in the future, the SPs can be involved before more decisions are made, as they are the cornerstone of building the Filecoin network.

[herrehesse]

We fully support the outlined plans and the shift toward a more rational and predictable fee structure for Filecoin’s onboarding process. As a large storage provider, we have seen firsthand the inefficiencies of the current system, making sector onboarding fees unnecessarily complex and unpredictable.

We strongly agree with introducing a per-sector fee to replace the batch balancer. This approach provides clarity, stability, and sustainability—allowing storage providers to plan for long-term investments without being at the mercy of base fee volatility. More importantly, we believe adding costs to extensions is absolutely the right move. Storage should be treated as a real economic service, not something indefinitely subsidized by block rewards. The days of relying solely on rewards to cover operational costs are over, and we must collectively shift our focus to securing paid deals as the foundation of a sustainable Filecoin economy.

This is the right direction for the future of Filecoin. We encourage rapid implementation and alignment across the ecosystem to ensure a viable, long-term storage economy—one that prioritizes real customer demand.

Discussions with lending entities are essential, as these costs should be shared between both the Storage Provider and the Lender.

[luckyparadise]

FIP-0100: Core Devs Endorse Proposed Changes, Final Steps Underway

After an extended Last Call period, Core Devs have reviewed FIP-0100 and reached consensus to move forward with the proposal, endorsing key changes based on community feedback. The FIP authors are now finalizing modifications to the spec to address concerns raised, particularly around fee adjustments and transition impacts for existing SPs. The recording of the Core Devs call will be made public on Youtube shortly.

Once these updates are incorporated and merged, FIP-0100 will be ready for acceptance. In parallel, Filecoin Foundation will support the formation of an ad-hoc monitoring committee to evaluate the real-world impact of this FIP post-deployment, ensuring ongoing assessment as the network evolves.

If you have questions or concerns, feel free to get in touch.