Simple termination fee, and export method for computing miner maximum aggregate termination penalty (FIP-0098)

[Schwartz10]

THE PROBLEM

In the year+ since FEVM’s launch, we’ve seen a number of protocols use Miner Actors as collateral for lending or leasing applications. Economic security of applications being built on the FEVM is important for developing trust, and understanding precise collateral values for any given miner actor is critical for a DeFi protocol’s economic security.

Today, it is both: (1) computationally expensive, (2) economically sophisticated, and (3) infeasible in a FEVM runtime to compute the maximum termination penalty for a miner actor’s sectors, which makes it infeasible to compute a "collateral value" (aka "liquidation value") for any miner actor. As a result, FEVM applications need to either (a) use heuristics to determine a collateral value for a miner (economically insecure), or (b) use off-chain solutions to compute collateral values (significantly bloating the surface area of attack vectors for any lending / leasing protocol).

Imagine running a lending business that accepts medieval coins as collateral, yet when you accept the coins as collateral, you either have to:

1. Guess what the true value is, and hope that what you lend out to the borrower is valued at less than the value of the coins you received (stfil)
2. Call someone outside of your business on the phone, ship them the coins, have them weigh and value the coins, and then send it all back with its collateral value (glif)

It's clear neither of these approaches sets the lending business up to run efficiently and without incurring unnecessary risk. It also provides unique and potentially unfair advantages to those that can accurately and quickly value miner collateral.

Exposing a method that will allow a caller to get a precise "maximum termination penalty" for any given miner on the network will allow folks to quickly and safely compute collateral values for miner actors.

Simply put:
collateralValue = availableBalance + initialPledge + lockedRewards - maxTerminationPenalties

EXAMPLES

The collateral value of a Filecoin miner deviates significantly, making it too dangerous to use any heuristic based approach without introducing risk-of-loss for liquidity providers. One way to inspect collateral value volatility in various miner actors is to compare their "recovery rates" - the amount of FIL that will be left on the miner after terminating every sector divided by the total balance on the miner. Take a look at the recovery rates computed on these two different miners (liquidation value / balance):

1. f033463 - 49.75%
2. f03137648 - 97.22%

In other words, assuming 100% of a miner's balance is pledged, a miner with a recovery rate of 50% will have a collateral value of half its balance, while a miner with a recovery rate of 90% will have a collateral value of 90% of its balance. There is no other easy to find signal one can use to determine these wildly different recovery rates besides actually simulating a termination of every sector.

So how is a lending business able to run with economic safety on FEVM today? Let's look at two real examples to discuss their strategies, both with pros and cons:

1. glif's approach (use an oracle):

• invest considerable resources to develop and maintain a liquidation value simulator that must stay accurate through network upgrades, fips...etc.
• the liquidation value simulator must work in two "modes": (1) on-chain termination of every sector using StateReplay, without triggering any termination queue by making several, successive calls to StateReplay for a small number of sectors. (2) off-chain termination of every sector by reimplementing the math in the built-in actor termination penalty method. We use these two methods side by side to make sure they report the same numbers. If they don't there was probably a network upgrade or a change in the liquidation value math.
• In both "modes", the liquidation value simulator can use a sector "sampling" technique so that we do not actually have to terminate every sector -> we take an average and use that to imply the liquidation value of all sectors. The sampling technique allows us to compute liquidation values for any miner in less than 30 seconds, however we lose up to 5% precision. It is not an option for us to use the precise (non sampling) method, as this could take hours and way too much compute resources to do over and over again. We would have far less traction and a terrible UX if borrowers needed to wait several hours to complete a single action.
• invent our own off-chain oracle that uses verifiable credentials and signed typed data to inject liquidation values about each miner into the smart contract environment, just-in-time for underwriting (so the protocol always has the most up to date information about the miner)
• spend considerable amount of resources on continuous monitoring of liquidation values against the precise vs sampled approach to ensure the samples we collected are not horribly inaccurate such that it adds risk to the protocol. For instance, sometimes the sampling approach will miss snapped sectors, which changes the liquidation value considerably for smaller miners.

The oracle service itself has cost us several hundred thousand dollars in audits, an enormous amount of security research, and a deep understanding of filecoin. This is not an option for pretty much any other dapp builder on the filecoin network, as glif is uniquely positioned from our long term work in this ecosystem, benefit-of-doubt on trust assumptions, enough resources from grants and venture capital...etc.

This approach necessitates the use of a server controlled by the glif team, which puts the business in a different regulatory position. And worst of all, oracles create a large security attack surface area of defi protocols. It doesn't matter how secure a smart contract is - if you write an insecure or inaccurate oracle, it's game over for your protocol.

2. stfil's approach (use heuristics, not oracles) (rip)

• treat rehypothecated collateral as 1:1 with liquid FIL - i.e. all balances on a miner are treated the same
• when setting leverage ratios, use the balance of the miner (dont worry about actual collateral value)

This is much simpler from a technical perspective, however, it introduces massive economic risk. In fact, when stfil was being shut down, our team did a deep analysis of the stfil active loans and found that many were massively under collateralized, yet the protocol itself recognized them as over collateralized. The hidden information was that the miners borrowing from stfil sometimes had unusually low recovery rates, so treating pledged collateral as 1:1 with liquid FIL was a major mistake and overestimation of collateral value. Even CeFi lenders have been using heuristic based, network wide approaches to recovery rates.

TENTATIVE SOLUTIONS

There are generally 2 approaches, both of which end with the ability to quickly and precisely compute the maximum termination penalty for a miner actor. From there, the caller can use the termination penalty to compute a collateral value for the miner.

1. Optimize data structures based on the current methodology to make an aggregate termination sector method feasible in constant time lookup
2. Simplify the methodology of how termination penalties are computed such that a heuristics based approach could work (safely)

Re option 1, here's one potential (naive) idea for the core devs, i'm sure it has many flaws. From our testing and research, the go implementation of builtin miner actor is still correct in computing termination penalties. Judging from the code, the penalty is a max between (i'm simplifying here):

1. A number that relies (at least in part) on some information that must be persisted in sector info at the start of the pledge (rewards at time of pledge activation)
2. A number that can be computed in real time based on current network conditions

The reason we must loop through every sector is to compute this max, which is different for each sector, solely because of the information that is used to compute #1. If we only had to look at #2 (current network conditions & sector power), my assumption is that we could run an algorithm that would use aggregate power on the miner (not per sector) to determine the termination penalty.

The change in data structure would be to add a new cached variable on the miner state itself that holds the aggregate twentyDayRewardAtActivation for all sectors, such that you could compare #1 and #2 described above on a per miner basis, rather than a per sector basis.

If this worked and maintained the mathematical integrity of the granular looping approach, it would alleviate the need for a highly complex and computationally intensive liquidation value algorithm, which would then enable lotus to expose this value in a precompile so FEVM smart contracts could use it

SUMMARY

• Computing the collateral value for a miner actor is critical for making economically secure defi protocols on filecoin
• Computing the collateral value correctly is hard on its own, impossible in a small time frame and/or from inside the FEVM
• The variance in recovery rates for different miners on the network vary so significantly that you cannot safely use heuristics to estimate miner collateral
• Either optimizing data structures or simplifying termination penalty calculations are two potential solutions to the problem

[Fatman13]

imho, we could remove termination fees all together to relieve core protocol complications. How termination fee is structured should be exposed to FEVM to allow clients and providers to dictate their own storage term instead of being severely limited by the core protocol defaults.

[The-Wayvy]

Def

[anorth]

#972 would only remove termination penalties for CC (non-QAP?) sectors. This would still remain a problem for FIL+ sectors. But a simpler termination fee calculation along the lines of @Schwartz10 #2 could work for all sectors.

[Fatman13]

#972 would only remove termination penalties for CC (non-QAP?) sectors.

i think termination fee would somehow make sense under vanilla Filecoin, but with FEVM introduced imho some of the previous protocol design choices have to be reconsidered, ie a revamped protocol master plan. I mentioned here in May 2023 about termination fee and its complications that it brought to defi. I personally advocates for removing both termination fees (CC and QAP sectors), as fundamentally imho storage terms should be between clients and providers not to be limited / interfered by core protocol.

[anorth]

I think the termination fee should be greatly simplified for this and other reasons. The current calculation also contributes hugely to chain state size and conceptual complexity (discussed in #691)

Either a flat termination fee that doesn't depend on history (your #2) or removing termination fees in return for an unlocking delay (see #972, but only for CC sectors) would be improvements all round.

[Schwartz10]

Strong agree, and flat termination fee that doesn't depend on history makes sense to me. So much simpler!

[Schwartz10]

A quick update on this discussion thread - @anorth and I started some high level brainstorming, and generally we both felt excited about simplifying the mechanism for computing termination penalties to a fixed percentage of either: (a) some amount of future block rewards given current network conditions and current power or (b) the total initial pledged balance

There are a number of different questions (each with their own sub-challenges) to answer when solving for this approach:

1. Choosing what to multiply the % by (block rewards or initial pledge)
2. Choosing what to set the percentages at (also deciding on cc vs dc sectors - should these be the same or different?)
3. Fleshing out an upgrade path (should changes apply to new sectors only? or retroactively apply to existing sectors?)
4. Any off-chain upgrade steps that an SP would have to incur that could create difficulty, more expenses, more challenges with operations...etc

As a first step, we'll collect some data about the network of miners, their power, and their termination penalties. Will keep the discussion thread updated as we learn more information // form any stronger opinions around valid mechanisms and approaches.

[anorth]

Here is some analysis of the termination fee and its ratio to pledge for sectors currently live on the network. This is based on a uniform random sample of 6.8 million active sectors a couple of weeks ago. (Note that the termination fee calculation used in this analysis is slightly simplified from the network and does not take into account the effects of upgraded CC sectors.)

Absolute termination fees vary widely and the variance is strongly correlated to the sectors activation epoch. This is expected since the termination fee calculation is largely based on the expected rewards at the time of onboarding. Per sector rewards decrease over time due to both the decaying block reward and the lower share of total power each new sector earns in a growing network. Multiple downward sloping trends are visible corresponding to 32 and 64 GiB sectors and to those with or without a Fil+ multiplier.

Termination fee as a fraction of pledge also varies in the same way, but here the pledge denominator unifies sectors with different power into a single trend line. (I think the unusually low-fee line visible along the bottom is an artefact of not computing the fee for CC-upgraded sectors properly). The current level is about 8% of pledge: 95% of sectors have a fee:pledge ratio > 8%, and 99% are >7.5%.

General results:

• Termination fees trend down over time and are lower now than in the past.
• Those downward trends started steep, but are becoming mild as the effects of initial network growth rates and the baseline crossing decline
• The average fee is not very representative of the distribution, and well above the fee that a new sector would face today

[Schwartz10]

Last week at the core devs monthly meeting, I presented the ideas written in this discussion. The general sentiment seemed positive and optimistic, and the main response was to propose something more specific for the community to consider.

2 potential solutions for calculating termination penalties

1. %-of-pledge - using percentage of pledge methodology, the termination penalty for any sector would be computed by multiplying the initial pledge of any sector by a fixed percentage (aka a penaltyPercentage).

The penaltyPercentage variable should be set such that it's a continuation of the current network condition. It should NOT be set as an average termination penalty across all active sectors on the network, since those results can be skewed upwards by outliers (see @anorth post here for more info)

This method would be extremely simple for anyone to calculate, which comes with the following benefits:

• Storage Providers can easily understand the penalties for termination
• Termination penalties can be computed in constant time, without considering network conditions, allowing for FEVM smart contracts to use more precise collateral values wrt Miner Actors
• A decent amount of state can be removed from the chain that is only there to compute termination penalties

In my opinion, this method is preferred because its the simplest.

2. multiple-of-daily-rewards - using some % or multiple of expected daily rewards to compute the termination penalty

This strategy would also significantly simplify the process of computing termination penalties. To compute the termination penalty for a sector, one could derive an expected daily reward number from a sector's power, and then use the expected daily reward number (along with some multiple or %) to calculate the termination penalty. A miner actor's aggregate termination penalty could be computed from its aggregate power.

While both strategies would accomplish the intended goal, I prefer strategy 1 because strategy 2 is still somewhat confusing for outsiders to understand, difficult to do in a "napkin math" kind of way, and contingent on network conditions (so harder to forecast). It also can result in situations where the termination penalty ends up being a large % of the sector's initial pledge, if the network baseline starts increasing quickly after pledging a sector when the cost to pledge was much cheaper. In other words, with strategy 1, Filecoin should be able to erase the concept of "fee debt". With strategy 2, "fee debt" could still occur.

Upgrade path

As long as the new termination penalties computed are not massively increasing compared to the current network condition, then it should be possible and not dangerous (actually beneficial for several miners) to upgrade existing sectors to have termination penalties computed in the new strategy. In other words, if we just take the current termination penalty of the network (which is already lower than the average sector's termination penalty), it should not negatively impact any miner on the network

I would strongly recommend against having differing sector types with different termination penalty calculations just to not change/touch existing sectors, however, this actually worsens the current problem that exists today (termination penalties are way too complicated to compute)

Eager to hear any feedback!

[anorth]

Great, thanks for a very concrete recommendation. It sounds good to me.

[Fatman13]

Using magic number seems ad-hoc-ish and potentially kicking the ball down the road, ie we could tweak the magic number in the next upgrade line of thinking. imho, removing all termination fee for all sectors seems to be the simplest and most rational given we are at post-FEVM era that storage terms could be settled between clients and providers with contracts and not to be limited / interfered by core protocol.

[Schwartz10]

@Fatman13 thanks for weighing in on this. I think we're on the same page about a desireable "end state" for filecoin with respect to fees/penalties being enforced by third party apps and protocols, but we may see things differently on the "steps to get there". This proposal gets us much closer to the end state that you describe while also introducing immediate benefits - i can't think of a good reason not to pass it even if it doesn't immediately fit 100% of what you're looking for. More notes below:

removing all termination fee for all sectors seems to be the simplest

Think it's important to clarify what you mean by "simplest" here - from my perspective, it's much "simpler" to implement the proposed solution in this discussion, even if solely for the reason of it's (a) not contentious, (b) easy to understand, and (c) does not block us from getting to the end state you describe.

I visualized this in a little venn diagram here:

removing all termination fee for all sectors seems to be the most rational given we are at post-FEVM era that storage terms could be settled between clients and providers with contracts

I generally agree with you here too - i think the bulk of disincentives towards deterring someone from terminating any sector type should come from a specific market smart contract that can enforce its own rules and collateral types. This makes the most sense because i dont think there exists a "one size fits all" penalty for every type of deal, and this type of strategy scales flexibly to fit any market type.

Using magic number seems ad-hoc-ish and potentially kicking the ball down the road

This isn't kicking the ball down the road on anything. It immediately gets us the majority of the way closer to the end state that you describe from both a technical and conceptual perspective - simply set the % of pledge variable to 0, and we've achieved the state you're looking for. Easy easy easy

If this FIP is passed, it immediately creates a foundation for safer Filecoin DeFi, and massively simplifies the conceptual design and code/state implementation of termination penalties. It is my strong opinion that we should not be holding up this FIP because we disagree on what the magic number is (0 or otherwise). It's way easier to lower termination penalties over time than it is to increase them.

[Fatman13]

Thank you for the reply. I think there is truth in your reasoning especially when taking current FIP governance process & other factors into considerations. Hope the network could eventually reach the "desirable end state" one day.

[steven004]

#844 (FIP-0078) is asking "Removing Restriction to Access to Multiplier and Allowing Unrestricted Minting of Datacap", which actually is asking eliminating real data governance involved in layer 1, and of course, it can be done on upper layer.

#1009 (Proof of Data Possession (PDP) [was PoCD]: Efficient Retrieval Provably Enabled) is a project which can take the role similar as Fil+ on layer 2, with decentralized provable mechanism.

With these in mind, I would think we could move to the target of elimination of all termination fee or slashing fee to make things much simpler.

That's why I am supporting all of these. Pass and implement FIP-0078 first, and implement the first version of PDP, which can be improved more later, and simplify the core protocol.

[Schwartz10]

Thank you for providing feedback @steven004 ! I agree that it is important to simplify the core filecoin protocol, and I see this fip as a major step in the right direction.

What do you mean by “pass and implement FIP-0078 first”? If you are suggesting to block this FIP until another tangential FIP is passed, I don’t think this is a good idea. I see no reason to create arbitrary blockers to pass this FIP especially when this FIP makes it easier in the future to eliminate fees all together (if that’s what the community agrees is best). This FIP will massively improve and further secure filecoin defi - why wait?

[raulk]

Chiming in to say that until this is solved, you can use tvx and the conformance test suite library to simulate a termination against mainnet and get an exact number. It's not on-chain, but it's the highest-fidelity off-chain solution we have today given it uses the actual actor code.

[AxCortes]

I understand the utility of having the Max Termination fee calculation be simpler, specially as more DeFI applications pick up, and sectors can be used as collateral.

I think actually a large part of the difference in % of slashable pledge between sectors, is more due to the initial pledge than the termination fee. For instance, in the example you give:

Take a look at the recovery rates computed on these two different miners (liquidation value / balance):

f033463 - 49.75%
f03137648 - 97.22%

I think most of the difference in the final result is due to difference in initial pledge, rather than termination fee calculation. And while yes the termination fees are different, maybe this particular example makes the problem look even worse than it actually is.

So I think part of the solution to the problem here is rather simplifying initial pledge. I think my Flexible target lock proposal goes some way into simplifying this, in that sectors would be free to pledge however much they want, and can choose to make things simpler.

That said, let's get back to simplifying the termination fee. Let's look back at the Filecoin spec that says what the Max termination fee is actually supposed to be doing:

A termination fee is charged that is, in principle, equivalent to how much a sector has earned so far, up to a limit in order to avoid discouraging long sector lifetimes... Termination fee is currently capped at 90 days worth of block reward that a sector will earn

Back then there were only 6 month sectors, and maximum termination fee was supposed to be capped at half of a sector's potential earning (Now there are longer sector lifetimes, but ok, let's say Max termination fee was still about 3 months of block reward). What is missing from the spec is that it doesn't specify which half of the sector's earnings we are talking about.

In the implementation of this idea, this was interpreted to mean, the initial half of sector's earning, So the initial state for all sectors must be remembered, and this yields different max termination fees for different sectors that were onboarded at different times.

One possible solution to simplify the termination fee calculation, is to keep the spirit of the spec's definition (3 months worth of block reward), but interpret that to mean, three months of expected future block reward, starting from present time. This calculation would be similar to the current calculation of the Storage pledge, which only requires the alpha beta filter predictions for total block rewards and network qap. So only 4 numbers need to be remembered (and they are already remembered for the storage pledge), and the same numbers are used for every sector, with everyone having the same termination fee.

One can argue "3 months of a sector's potential earnings" is too high or too low, but that's at least what the current spirit of the definition is, whether we think it is too high or too low is a separate discussion that is not about simplifying the termination fee, but about changing it.

[anorth]

Thanks @AxCortes these are good points and help focus the discussion.

Firstly, I think your proposed possible solution is the same as, or very close to, option 2 presented by @Schwartz10. It could be simplified even further to ignore the alpha/beta projections and still have the same practical effect (I'm not sure whether @Schwartz10 intended to use the projection or not). But here we can see good alignment and if this were the ultimate outcome then I think we'd all consider it a worthwhile improvement.

You're right there's a further part of the discussion which is more about changing the calculation method of the fee. Given the high cost of making change, if we're going to touch it, what would be an even better outcome? I think this is worth designing and debating this at the same time.

In my opinion, the spec's basis for a termination fee is outdated. I summarised a range of possible motivations for a termination fee in #691 (comment) . The spec doesn't give any justification for the capped half of rewards, but my best understanding of it is a combination of client assurance, enforcing "commitments" and stability of storage and pledge. Of these, the only one I believe to be well-conceived and justified is stability. There seems to be broad agreement that client assurance should largely be left to negotiations between providers and their clients rather than a network built-in, and "commitments" is just moralising. Stability of the bases of network security (especially pledge, which dominates), is more reasonable.

Denominating termination fees in pledge would directly tie the penalty to the desired stability. This is the same conclusion reached in #972 (comment) (though that discussion then proceeds to find a way to replace penalty with an unlock delay in the case of CC sectors).

I think you're right to attribute a large part of the difference in the recovery rate example to different pledges. From another point of view, the difference in recovery rates is because the TF is ignoring the pledge! If we adopted something like your flexible target lock, or an alternative that would generate more variance in pledges, I think TF based in pledge is exactly what we'd want. Otherwise SPs could engineer an extremely low cost of churning pledge by putting massive pledge against few low-fee sectors. Other conceivable future changes could be supporting zero-pledge sectors (no power/rewards, just serving clients) and no-storage pledging (rewards for network economic security) and I think again in these cases, TF aligned with pledge is closer to what we'd want (no TF for zero-pledge sectors, unstaking costs a fee or unlock delay).

So, if we can't gain broad alignment that pledge is a better basis for TF, at least simplifying them based in BR is still a step forwards. But I believe the spec's conception of termination fees is flawed or at least outdated, and if we're going to change it we can do better. Note in all cases I'd favour maintaining the nominal fee for a new sector at the current levels [edit: except reducing for CC might be ok].

[Schwartz10]

Thanks for weighing in @AxCortes ! I strongly agree with @anorth opinions in the comment above.

The only other thing I would add is that on top of pledge being a better basis for TF from an economic perspective, it's also a simpler conceptual design, which has positive benefits. It makes it easier for SPs and devs to reason about without having to know, understand, or make predictions about the state of filecoin's future block rewards.

[AxCortes]

I am not against the idea of a FIP doing two things: simplifying AND changing the amount of termination fee. Just that then it should be clearly stated, say in the title as "change in termination fee" and not just "simplification". I agree parameters are difficult to change in Filecoin, and if we think it should be changed, better to use the same opportunity.

I think the Max Termination fee is meant to be sort of the opposite that you describe. What provides the "commitments" and stability is the definition of termination fee that says "All the block rewards the sector has earned so far". This is pretty dramatic, but ensures this incentive, that the strategy of terminating your sector before you're supposed to has negative utility.

What the "Max" termination fee does is try to control in the opposite direction for how dramatic this is. The reason we have a max termination fee is "to not discourage long term sectors". Because the longer your sector has lives, the larger an amount "all the block rewards the sector has earned so far" is. So the spec states the rule, we want this rule, up to some point, when the punishment becomes too large, and now it is discouraging long term sectors.

Since Termination fee in general is defined in terms of block rewards, this is why it makes sense to me that Max termination fee is also defined in terms of block rewards. Initial Pledge and block reward will continue to have diverging ratios over time, but max termination fee should be attached to block reward, as termination fee is.

[Schwartz10]

Sure that's helpful feedback about you interpreting simplifying as "not changing" - i don't see how such a thing is possible (simplifying term fees without changing them), but I'll incorporate this feedback in the fip draft title.

I think we're on the same page about the appetite for termination fees in general, but we may disagree on the significance of fees being denominated in block rewards. Term fees are meant to do a couple things:

1. Create a more resilient storage network for storage clients, such that if an SP stores a client's data, the client isn't just suddenly left out to dry and their data lost
2. Network stability

We can see in practice that termination fees don't actually accomplish number 1 very well. Your point: "This is pretty dramatic, but ensures this incentive, that the strategy of terminating your sector before you're supposed to has negative utility." is not always true, even when block rewards are high. This is largely due to the fact that Storage Providers still value their cost basis in fiat terms, not FIL terms. Terminating a sector early guarantees negative economic FIL-on-FIL consequences, but it does not guarantee negative economic fiat denominated consequences. For instance, even if the termination fee is 30% of the pledge, an SP is economically better off terminating all sectors and selling if the price of FIL will fall >30%.

Re point 2 - today we are operating in a network with very low termination fees as a portion of initial pledge, and the network power isn't super volatile. We know from practice that unless a Storage Provider has a major change in funding (i.e. investors decide they want to sell FIL), that the Storage Provider does not want to take any fees (even 5% is a lot to them), so they won't just magically terminate willy nilly unless there's a forced reason. This is proven even in extreme scenarios - during the stFIL incident, a storage provider I know wanted to wait out the risk of losing 100% of their miner collateral because they didnt want to terminate to lose 10% (which was their fee as a portion of pledge at that time). Regardless, I don't think denominating the fee in fixed % vs block reward terms makes a significant difference to the Storage Providers when they have to terminate sectors

Since Termination fee in general is defined in terms of block rewards, this is why it makes sense to me that Max termination fee

This proposal is to set termination fee == max termination fee, there wouldn't be a difference.

My last point, Storage Providers that are actually creating value for paying storage clients have a lot more to lose than some FIL on a sector basis when terminating an SLA - these are data center businesses, so they lose reputation, deal flow, customers...etc. Since there are so many variables for a storage provider in practice, it doesn't make sense to treat the termination fee as if its the only factor an SP considers when terminating sectors. We don't have to get too elegant with implementations to accomplish the end goal - the simpler the better

[anorth]

I have replicated the analysis above on a new raw sector data export provided by @rvagg (see here). The correlation charts look essentially the same, so I won't re-post them.

For selecting a policy value of the ratio of termination fee to pledge.

• The most recent value is 8.8%
• The last 750,000 epochs (260 days) have a very tight mean around 8.4%, with s.d. of 0.4%. The range over that period is 8.1%-8.8% (so it's trended up recently from a low, vs an overall strong downward trend long term)

I would propose a value of 8.5%, being just on the recent mean. It's likely this would represent a small reduction in risk to new sectors onboarded at the time this change could go live.

As an aside, I observed that some of the oldest sectors have a termination fee over 200% of the initial pledge! Another sign that the current methodology is inappropriate.

[anorth]

The first draft of FIP-0098 specifying this is about ready at #1079

[irenegia]

@anorth I have a question about this: in the original design of storage fees (ie, fault fee, invalid proof fee and termination fee) we requested that TF > FF, otherwise an SP could terminate the sector to avoid paying FF for detected faults.

With the new proposed formula (TF = % of IP), in the future, it could be that the condition is TF > FF is not true anymore (say for example that we will change the IP value). In this case if a sector becomes faulty, terminating it is the rational (ie cost effective) strategy, which it is not optimal imo. We would like to se SPs try to recover fault sector instead of terminating it.

A solution for this would be setting TF = max{% of IP, 1.05*FF}.

cc @lucaniz

[irenegia]

For more context, the requirement of TF > FF came from the following reason:

Consider the case of a malicious SP deleting more than 20% of a sector’s data. If the SP gets lucky, it could still successfully pass the PoSt verification (10 challenges means this can happen with non-negligible probability). In this scenario, the SP incurs zero storage cost yet still has a positive expected reward, which is problematic. The Fault Fee (FF) is designed to counteract this issue by ensuring that: expectedReward−expectedCost < 0

An edge case considered during the origianal design phase is the following: What if a malicious SP, instead of risking a failed PoSt and paying FF, voluntarily terminates the sector just before the deadline (or after seeing the challenges are bad for him)? This would allow the SP to pay the TF instead of FF. If TF is lower than FF, this could create a profitable attack case.
I am open to removing the TF > FF constraint, provided we have other protocol ways to prevent SPs from using termination to bypass fault fees. I believe this is already the case in the current version of the protocol (i.e., once PoSt challenges have been issued, a sector’s state cannot be changes to avoid penalties). But, we need to:

• Verify this behavior in the current protocol.
• Check for other potential edge cases that could create similar exploits.
• Clearly document this in the Security Considerations section of the FIP.

[Schwartz10]

@irenegia thank you! this is quite helpful and very well thought through.

I better understand why TF = max{% of IP, 1.05*FF} is a preferred solution. The intention of this FIP should not be to change the incentives of mining such that a malicious action nets a positive expected reward.

After thinking about this more thoroughly, I've realized that as long as the calculation of termination fee is not computed on a per sector basis, and can be done on a per miner basis in a smart contract environment, there's no reason TF = max{% of IP, 1.05*FF} can't be an adequate solution.

@anorth - motioning to revise this FIP to propose something slightly different, with additional precompiles to help FEVM actors work through the math:

• Termination fee calculation is TF = max{% of IP, 1.05*FF}, where % of IP remains at 8.5%

Additionally, new FEVM precompiles to help FEVM actors compute fees in the slightly more sophisticated model:

• Precompile (most important / highest priority): getMaxTermFee(minerID) => returns max{% of IP, 1.05*FF}
• Precompile (also quite important as "at risk capital"): getInitialPledge(minerID) => returns IP for a miner
• Precompile: getMaxFaultFee(minerID) => returns 3.51*BR
• Precompile: getExpectedBlockReward(power) => returns the BR for an amount of power (number that is used to compute FF)
• Precompile: getActiveSectorCount(minerID) => returns # total sectors for a miner
• Precompile: getTermFeePercentage => returns the % of IP, today at 8.5%

With these precompiles, FEVM actors that rely on miner actor collateral should have no issue computing termination fees in real time, inside smart contracts. Including the precompiles to calculate FFs will be helpful too, as FEVM actors that rely on miner collateral can discover how long they have in a faulty sector environment before they get into a dangerous position wrt miner collaterals.

Only blocker here would be if aggregate FF per miner needs to be the sum of FF per sector, and can't be computed in one go in the aggregate. I don't see why that would be the case if FF just has to deal with generic expected block rewards for an amount of aggregate power. If that's the case, we should figure out a better way to compute aggregate max FF per miner without looping through every sector.

[anorth]

A miner actor doesn't quickly know it's own power (but does know it's pledge). This means that a calculation of the fault fee for all sectors cannot be made from within the miner without iterating all partitions. But the miner's power is known by the power actor.

The fault fee is a function of

• network reward alpha/beta projection
• network QA power projection
• QA power being faulted

The reward and power projections come from the reward and power actors respectively.

So

• During termination, a miner will use the per-sector info because it's loading it anyway
• From outside the network, the max FF of all a miner's sectors is computable by looking up the miner's power in the power actor, and then using the reward & power projections
• From a smart contract the max FF for a miner would be computable if smart contracts could access the necessary inputs: the network reward and power projections, and the miner power

Right now smart contracts can't access any of these inputs. I don't think there's any fundamental reason we can't expose them. Although, given this motivation, maybe it would be better to abstract the fault fee calculation and expose a calculator for it instead, which will then keep working if fault fees change in the future.

As to specific precompiles, I would rather expose somewhat general building blocks rather than something too high level. I think calculating the maximum termination fee for a miner is application logic rather than network built-in, even if we have constructed the network to make it easy to compute.

• Fetching a miner's QA and raw power 👍
• Fetching a miner's initial pledge 👍
• Fetching the network projected expected power and reward seems ok, parameterized by the projection period. Note the two below would hide this so not strictly necessary to export
• For the fault fee calculation (abstracting the 3.5 day projection period) I think it would be better to expose a method that takes as input the amount of QA power for which the fault is being calculated, rather than a miner ID. This would make it more widely usable
• For termination fee calculation (abstracting the 8.5%), take as input a pledge and power value. Similarly more widely usable than a miner ID.

A SC could then fetch the pledge and power values for a miner, then compute the max termination fee. (And could also compute fault fees independently, though not necessary for this proposal). The minimal new precompiles would be three.

[Schwartz10]

@anorth this all sounds good and reasonable to me. I'd defer to you on the "how", and it seems like you have a good grip on the highest priority intention of this fip - to make it possible to compute termination fees on chain. So long as it's possible, I personally would be on board to move forward.

In terms of a "wish list" and secondary priorities, I would say:

• Expose building blocks in a way where downstream protocol does not have to change its parameters or formulas if filecoin changes (i.e. like you mentioned - "maybe it would be better to abstract the fault fee calculation and expose a calculator for it instead, which will then keep working if fault fees change in the future"
• Expose (in addition to other things) a complete termination fee calculator, in full, that builders can rely on to accurate compute termination fees

[rvagg]

FIP text has been merged and is apparently in Last Call but I don't see details of TF = max{% of IP, 1.05*FF} or anything similar in there, unless I'm missing something?

I also don't see any details of anything that's exposed to smart contracts as part of the FIP, there's only a brief mention of "can be computed (or returned by an FEVM precompile)". Does that mean that this FIP would have a follow-up FIP to expose methods at a later upgrade and that just having it simplified is enough for now?

[nobsu]

Suggest removing the termination penalty and replacing it with a delayed release mechanism. In most major PoS blockchains, staked assets can be withdrawn at any time without penalties. To protect the network, an unstake waiting period can be introduced—for example, FIL would only be available 10 days after sector termination. This approach reduces financial losses for miners while maintaining network stability.

[anorth]

This approach has been proposed for CC sectors in #972. I think it could work fine for those. The proposal needs a concrete implementation to be specified: how to implement the waiting period. It's not trivial since the pledge is attached to specific sectors. (It would be much simpler if sectors had homogenous pledge). If you'd like to help figure out the details, I suggest doing so in that discussion.

I don't think delayed release is appropriate for sectors with data in them. For those sectors, the pledge and termination penalty is not just a simple staking thing. The pledge/penalty is protecting specific data in those sectors and clients may be relying on those economic penalties as part of their service assurance. This is especially the case for FIL+.

[gitgavinzhao]

It depends on how you look at the current network data. If it is meaningful real data, the inability to efficiently copy copies and transfer copies before sector termination is unacceptable to users, not just a matter of cost.
If it is determined to be a kind of junk data in another sense, obviously there is no need to consider so many issues.

[Schwartz10]

Related post from a while back in this discussion - #1036 (reply in thread)

this fip does not make it any harder to get rid of termination penalties all together (in fact, i would think it should make it much easier to reason about), should that be what the community decides its best. But we should not hold up making filecoin improvements along the way, even if it may not be the final solution

[gimims]

We discussed with customers and SPs, and the support rate was not high:

1. Many SPs borrow FIL from platforms such as Haven, and then pay a percentage to the computing center. If modified, SPs need to pay more.
2. The economic model is a very important content, which was determined before the launch of the FIlecoin mainnet. Modifying the economic model will bring changes at the consensus level. Reduce the market's confidence in FIlecoin.
3. The trading market has strong uncertainty, and the price of FIL fluctuates greatly. Increasing the pledge means increasing the cost of SPs, and SPs may choose to leave the FIlecoin ecosystem.

[Schwartz10]

This proposal has to do with simplifying the termination fee for miners, it has no effect on the rewards or returns for SPs. It is easier for lenders like GLIF and Haven to lend more FIL to SPs when the termination fee is simpler.

[diogohavendp]

@Schwartz10 to the point made above, having an increasing TF from sector activation until it reaches day 140 (current implementation) gives SPs the opportunity to build a collateral balance as they go (with rewards), thus reducing the initial collateral needed from SPs to onboard data.
I agree with your point that this does not affect rewards whatsoever and overall profitability, but it's true this will increase the initial requirements for SPs to be able to raise more FIL from capital providers.

[diogohavendp]

@Schwartz10 I left a comment in the slack discussion, but re-posting here for the remaining audience:

1. In order to raise FIL from capital providers SPs need to provide upfront collateral/contribution (just like in GLIF), and this collateral/contribution is based on potential slashing events:

• TF being one of the potential slashing events, if the calculation of TF changes, so does the SP initial collateral/contribution required by capital providers (Haven being one of them)

2. Therefore, if we change the way slashing fees are calculated - in this case by increasing TF for the period since sector activation to day 140 (after day 140 the 8.5% is in line with current implementation) - so does the required collateral/contribution SPs need to put upfront

Here a more graphical visualization of this FIP suggested change:

3. Is there a way we can simplify the termination fee calculation (which I agree with as we share the same computational issue GLIF is facing, although we've it implemented and running) at the same time it doesn't impact the linear daily function from sector activation to day 140?

[Schwartz10]

Hey @diogohavendp I understand better what you're saying now - SPs are required by CeFi lenders to lock more FIL if there's no gradual TF increase over time until day 140. This means more cash down up front. I agree it would not be good to make a change that suddenly causes ecosystem stakeholders to go under-collateralized.

The most important part of this FIP discussion is to set a max value for TF that is reasonable (8.5%). It does not actually matter if the realized TF is strictly lower. For this reason, we could try and maintain the existing 140 day build up of TF (or implement it in a much simpler way with the same end result as current network conditions). I would defer to @anorth on technical complexity there.

[beck-8]

Just a reminder here. Because some content has been modified in previous version upgrades.
If the sector is renewed between 144-540 days in the graph, the termination fee will increase sharply, and then decrease to the maximum termination amount of 140 days in the next 140 days.

[gitgavinzhao]

This seems like a strange solution. Obviously the problem of FEVM's computing power undermines the promise of the network: that is, the SP accepts the penalty and is free to leave the network.
Obviously this is a technical problem that affects the business, and the need for technical solutions is a way that has less impact and is easier to reach agreement.
The discussion on the modification and upgrade of the fee model should obviously not be limited to this trigger point, but should consider the interests of all ecological participants (how participants participate is still a big question, vote?)
Although participating in the discussion is respectable, it always shows that FF has no overall plan, feels where it goes, and there is no consistency and transparency in the reasons for changes.

[Schwartz10]

@gitgavinzhao I don't understand what you're suggesting - this is a technical solution to the problem, it significantly improves the concept of termination to make it easier to understand and reason about, which allows the filecoin defi ecosystem to more easily flourish.

The FF has nothing to do with this - this proposal comes as a result of observing how Filecoin has been working over the last few years, adjusting based on real knowledge and experience, and making a simpler/better solution moving forward. If we hold up the network from getting simplifications and improvements, it won't grow and mature in the ways it needs to

[Schwartz10]

After considering a second round of comments / feedback / suggestions, this comment represents a revised solution for the FIP Discussion to simplify termination fees. It revises the algorithm for computing fees, and outlines the required precompiles to compute the TF from application logic.

The proposed maximum termination fee formula should be:

TFmax = max{% of IP, 1.05*FF}.

The consideration with TF > FF satisfies @irenegia requirements.

This max termination fee can be applied on the miner as a whole, and on a per sector basis.

The realized termination fee formula per sector can be less than the max computed above if the sector is younger than 140 days old. I've checked with @anorth and it sounds like this is doable and not adding technical complexity because the miner actor already loops through each of its sectors.

TFreal = max{% of IP, 1.05*FF} * min(1, x/140) where x = sector age (days)

The min(1, x/140) part of the algorithm maintains the linear increase in TF over the first 140 days of sector activation to alleviate @diogohavendp concerns. Note that several folks in this fip would advocate for removing this in a future fip/upgrade - it doesn't make sense for it to be cheap for SPs to be unreliable early on and expensive to actually provide service for a time and then fail later,

Given the revisions, there are also proposed FEVM precompiles:

1. Fetching a miner's QA and raw power
2. Fetching a miner's initial pledge
3. Fetching the network projected expected power and reward, parameterized by the projection period
4. Fetching the termination fee constant % (8.5%)
   (the below 2 precompiles could also be built as a FEVM native oracle contract instead of as an FEVM precompiles.
5. Fetching the single fault fee calculation, parameterized by an amount of QA power
6. Fetching the max termination fee calculation, parameterized by an initial pledge and power amount

[Stebalien]

Implementation note: builtin-actor methods and precompiles aren't the same thing. These would be methods on builtin-actors (on the miner actor or the power actor or both).

[diogohavendp]

@Schwartz10 thanks, I am ok with your proposal.
I must make the point that If I'm getting your proposal right regarding the linear increase, one may argue that the starting point is much lower than the current one.

Looking at day 1:

• Proposed: 8.5% * 1/140 = 0.06%
• Current: ~2%

Maybe set-up it up as

TFreal = max ( 2%, max{% of IP, 1.05*FF} * min(1, x/140)) where x = sector age (days)

?

[Schwartz10]

@Stebalien thanks for the correction - I've reflected the correct language in my updates to the actual FIP. It is still important that these built-in actor methods get exported so they're accessible in the FEVM (this is what i really meant).

@diogohavendp good call (as far as I can tell) - i've included this suggestion in the fip changes

#1128

[rvagg]

@diogohavendp can you clarify your 2% please, 2% of what? FF? and are you intending it in your equation to be a multiplier of FF, so TFreal = max (0.02*FF, max{% of IP, 1.05*FF} * min(1, x/140))? Or some fixed number that's 2% of something today?

[diogohavendp]

@rvagg 2% of the IP. This 2% comes from the current implementation that terminating a sector upon activation has a TF of around 2% of IP.

[Stebalien]

I can't find anything in the FIP that ensures that repeatedly faulting is more costly (in terms of fees) than termination.

Ideally, more than N (e.g., 7) faults in a row would cost more than simply terminating a sector. That way clients/markets can react to terminations assuming that a rational SP will terminate "bad" sectors rather than just leave them faulty.

• This makes it easier to build markets on Filecoin assuming we eventually expose some form of on-chain termination events. Fault events don't scale well in general.
• This would also let us eventually simplify cron by letting SPs handle termination. Right now, sectors are automatically terminated after 40 days of faults but, ideally, it would simply be in the SPs best interest to terminate sectors after N days of faults and we can leave the decision up to the SP.

I guess my proposal is to bound TF as: 1.05 * FF <= TF <= 7 * FF (where 7 could be 14, etc., but some reasonably small number of days).

[irenegia]

Right now, sectors are automatically terminated after 40 days of faults but, ideally, it would simply be in the SPs best interest to terminate sectors after N days of faults and we can leave the decision up to the SP.

When a sector is terminated after the 40 days of faults, does it pay TF?
I think yes (but i didn't check the code). If I am correct and it pays, then it is already rational to declare termination as soon as you know you are not able to recover that sector.

If it doesn't pay, then yes: in order to be sure that timely termination is declared we need TF < X * FF and I think X = 14 is a good value.

[Stebalien]

Ah. You're right, it does pay the termination fee regardless.