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]

I'm more like asking another question here, is the system complexity much more complex than it would have been no matter where or how the deduction is made from? Because it has to deal with all sectors of all SPs.

[Stebalien]

TBH, this is a tiny drop in the complexity of Filecoin itself. Dealing with all sectors of all SPs is already something Filecoin does every proving period anyways.

[irenegia]

@Stebalien

1. Yes, the fee comes form the miner actor (as the "owner" of the sectors)
2. Good catch! In the fip I forgot to mention about the case of skipped windowPoSt. Yes, i agree that in that case the daily payments has to be handled by cron, I think we can do that at the same time as we remove powers fro those skipped sectors. If you agree this is a good design , I'll updated the fip description.
3. I always assumed this fee will follow the same system as fault fees. Why do you think this has not the right incentive?
   • About "should miners that don't have sufficient power to win blocks pay this fee?" Again, i think we should follow the same logic as fault and termination fee, but happy to evaluate other proposals

[Stebalien]

(summarizing an out of band discussion)

Unfortunately, checking if a miner is eligible will add 1M+ gas to every WindowedPoSt message and likely isn't worth it for the very tiny number of StorageMiner actors that aren't yet eligible to mine. Furthermore, fee debt is less critical in this case because these StorageMiner actors are already ineligible to mine, so fee debt doesn't really matter for them.

[rvagg]

Implementation discussion today suggests that it's just going to be simpler and more logical to move daily processing into cron and avoid WindowPoSt entirely—since we have to deal with skipped posts anyway.

Edit: discussed below: #1105 (comment)

[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]

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.