CPR-SA: Termination Fee

# CPR-SA: Termination Fee ###### tags: `filecoin-pl``Protocol Review` *Authors: Danilo Lessa Bernardineli (BlockScience), Jamsheed Shorish (BlockScience)* ___ *Meta* - Title: Termination Fee: Ensuring Sector Permanence ## Introduction :::success ok ::: In this article, we’ll explore an important mechanism in the lifecycle of storage brought to the Filecoin ecosystem, the Termination Fee. The Termination Fee mechanism is a combination of _participant_ decision-making regarding the availability of a sector of storage to the network, and a _protocol_ incentive structure to ensure such availability. This combination balances the two types of inputs in a way which is designed to maximize the likelihood that the ecosystem can rely upon storage that is both 1) error-free, and 2) dependable at least up to the time of sector expiration. ## What is the Termination Fee? :::success ok ::: According to the [Filecoin Spec](https://spec.filecoin.io/), the Sector Termination Fee is a dynamically adjustable fee that is assessed to a storage provider. This fee is "triggered" under one of the two following conditions: 1. The **storage provider** may decide to make a sector of storage unavailable prior to its sector expiration. In that event, the sector is terminated and removed from availabilty, and the Termination Fee must be paid by the storage provider. 2. The **protocol** may detect that a sector has not been available, i.e. has been "faulty", for more than **42 consecutive days**. In that event, the sector is terminated and removed from availabilty, and the Termination Fee must be paid by the storage provider. As of this writing, the Filecoin specification defines the Termination Fee as a combination of capped penalties, based upon both what a storage provider has already paid in terms of storage pledge, and what they would expect to earn from sector rewards. The numbers are taken from the [source code](https://github.com/filecoin-project/builtin-actors/blob/b7ad2c55363c363f61275ca45ef255e28f305254/actors/miner/src/monies.rs). These combinations may be broken down as follows: 1. First, the Termination Fee is only applied up to a certain maximum number of days, known as the `CappedSectorAge`. This maximum is currently 140 days, so that if the current age of the to-be-terminated sector is `SectorAge`, $$ CappedSectorAge = \min(140, SectorAge). $$ 2. For each day in the sector's age, up to the `CappedSectorAge`, the estimated block reward `ExpectedDailyRewards` is assessed (this is computed elswhere in the protocol), and the total is then _discounted_ by $50\%$. The result is the `CappedExpectedEarntRewards`, to be assessed as part of the Fee: $$ CappedExpectedEarntRewards = \frac{ExpectedDailyRewards * CappedSectorAge}{2}. $$ 3. In addition to `CappedExpectedEarntRewards` there is also a _forfeit_ of the collateral Pledge, the `SectorStoragePledge`, made earlier by the storage provider; together these comprise the `BaseTerminationFee` of the sector: $$ BaseTerminationFee = SectorStoragePledge + CappedExpectedEarntRewards. $$ 4. It may be that the sector has been unavailable due to errors, or _Faults_, for a period of time leading up to termination. These create an additional penalty, `FaultFee` and `FaultDetectionFee`, which is also assessed at the moment of termination (together these fees are roughly 3-1/2 days of expected sector rewards), and make up the `SectorPenalization`: $$ SectorPenalization \approx FaultFee + FaultDetectionFee $$ 5. Finally, the protocol selects the _maximum_ of the `BaseTerminationFee` and the `SectorPenalization`, to arrive at the `TerminationFee`: $$ TerminationFee = \max(Sector Penalization, Base Termination Fee). $$ For most cases the `BaseTerminationFee` is expected to be larger than the `SectorPenalization`, because it contains the Sector Pledge of 20 days' expected Block Reward at the time of activation (vs. the 3-1/2 days' Block Reward contained in `SectorPenalization` at the moment of termination). It is possible, however, that in rare situations `SectorPenalization` may exceed `BaseTerminationFee`---for example, a sudden drop in Network QAP relative to a sector's QAP could boost the Block Reward at the time of termination significantly, possibly outweighing the `BaseTerminationFee`'s Block Reward inclusion from the time of sector activation. For a Sector which is active for more than 140 days and which the `BaseTerminationFee` is larger than `SectorPenalization`, the **Termination Fee will be calculated at 90 days of expected Sector Daily Rewards**. Lastly, it can be worthwhile differentiating the cost to Passively Terminate Sectors with the cost to Actively Terminate Sectors. The first one should also include 42 days worth of Sector Fault Fees (defined as 2.14x daily expected rewards) and 1 Fault Detection Fee (defined as 1.5x daily expected rewards). Taken together, the **Maximum Passive Cost will be of ~91.4 days of expected Sector Daily Rewards in addition to the Termination Fee, or a total of ~181.4 of days expected Sector Daily Rewards** ## Termination Fee Examples :::success ok ::: It can be helpful to understanding the Termination Fee functional form given above with a few example "scenarios" built around different block rewards for a sector. In 'Scenario 1' it is assumed that the block rewards are a constant 1 Filecoin token (FIL) per day, while by constrast in 'Scenario 2' block rewards increase to 10 FIL daily from Day 10 (the initialization date of the sector) to Day 30, and gets back to 1 FIL per day thereafter. The resulting values of `TerminationFee`, `BaseTerminationFee`, `SectorPenalization` (all in FIL) and `CappedExpectedEarntRewards` as a fraction of the `TerminationFee` (as a percentage) are presented in the figures below. In the figures, the left vertical axis indicates the Fee value in FIL and the right vertical axis the earnt rewards as a percentage of the Fee, while the horizontal axis represents the time elapsed since the sector's initialization. As we can observe, Termination Fee starts out as being the Storage Pledge of the sector (20 days of Daily Sector Reward), and it increases until it becomes the Storage Pledge plus 70 days of Daily Sector Rewards. The exception happens when the Actual Rewards are way larger than the expected Rewards. It is also clear that the **Earnt Rewards tends to be larger than the Termination Fee, except on the very beginning** of it - on Scenario 1, Termination Fee becomes smaller than the Earnt Rewards after 40 days. *Termination Fee Calculations for a new sector under two stylized scenarios. In order to the Sector Penalization to be relevant, the Earnt Rewards must be way larger than the Expected Rewards. [Source](https://docs.google.com/spreadsheets/d/1COsTZjW-Yn6LcrxYvwJ7CJCbcoYUaBRcGMttCfjb0QQ/edit?usp=sharing)* | Constant Day Rewards | Increased Day Rewards by 10x for 20 days| | -------- | -------- | | ![](https://hackmd.io/_uploads/SypHhF00j.png)| ![](https://hackmd.io/_uploads/SkrL2F0As.png) | ## Termination Fee when Upgrading a Sector :::success ok ::: When a Sector is upgraded, the Expected Daily Rewards does change. In order to take into account that, the Termination Fee takes a different shape with old sectors. The Base Termination Fee will depend instead on the `RelevantExpectedEarntRewards`, which is defined as: $$ RelevantExpectedEarntRewards = CappedExpectedEarntRewards + ReplacedExpectedEarntRewards. $$ $$ ReplacedExpectedEarntRewards = \frac{ReplacedExpectedDailyRewards * RelevantCappedSectorAge}{2}. $$ $$ RelevantCappedSectorAge = min(ReplacedSectorAge, 140 - CappedSectorAge) $$ The Replaced Expected Earnt Rewards represents how much were earnt before the upgrade, and up until an limit. The reason for this design to disallow sectors to take advantage of an reduced Termination Fee when upgrading. The following table and illustration demonstrates the expected behavior. If the Sector being Upgraded is older than the sector age cap and the new Expected Daily BR is lower than the old one, then it is expected that the Base Termination Fee will go down with time. If is newer than the cap, then the Fee can go up for an duration and then go down. ___ *Example of the Base Termination Fee calculation after an upgrade.* |Metric|Before Upgrade|0 Days After Upgrade|50 Days after Upgrade|140 Days after Upgrade| |-|-|-|-|-| |Expected Daily BR|3 FIL/day|1 FIL/day|1 FIL/day|1 FIL/day| |Sector Age|90 days|0 days|50 days|140 days| |20d at Activation|60 FIL|60 FIL|60 FIL|60 FIL| |$RelevantCappedSectorAge$|0 days|90 days| 90 days| 0 days| |$ReplacedExpectedEarntRewards$|135 FIL|135 FIL|160 FIL|70 FIL| |$BaseTerminationFee$|195 FIL| 195 FIL | 220 FIL| 130 FIL| ___ *Base Termination Fee calculation for a 3 expected FIL/day, 90 days old Sector being upgraded to a 1 FIL/day one. Vertical axis indicates the Base Termination Fee in FIL and horizontal axis indicates how much days have passed since the upgrade. [Source](https://www.desmos.com/calculator/d201lninev)* ![](https://hackmd.io/_uploads/rktIoM9b3.png) ## Challenges and Risks associated with the Termination Fee :::success ok ::: As of this writing, there are differences between what is communicated in the [Filecoin Specification](https://spec.filecoin.io/#section-systems.filecoin_mining.sector.sector-faults) about the Termination Fee and what is actually contained in the protocol code. This makes it difficult not only to understand the current implementation of the Fee, but also to comprehend the interactions and dependences between the Fee and other components of the Filecoin ecosystem. Examples of such interactions include: 1. Updates to the Filecoin Network's Economics have not always been with a general systems perspective, leading to piecemeal updates of one component without correponding changes to other components. For example, the period of observation for consecutive days of faults increased to [6 weeks](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0026.md) from 2 weeks, without a corresponding change to Storage Pledge requirements. This can make the Termination Fee comparatively cheap (as compared to repairing the sector) if onboarding costs are relatively low. 2. The Termination Fee has multiple dependences upon the Network state at the point of the sector's `Activation Time`. This can be a tricky situation to assess, as for a fixed Quality-Adjusted Power (QAP), as we can expect the sector Storage Pledge and expected daily rewards for a sector being onboarded or upgraded to go _down_ over time. 3. The Termination Fee _can_ depend upon the sector Expected Rewards at the time of termination (currently 3-1/2 days of the expected sector Block Reward). However, this dependence should be considered as rare for 'mature' sectors, since it would require that `SectorPenalization` exceeds the `BaseTerminationFee`, i.e. that the 3-1/2 days of expected Block Reward exceeds the sum of the Storage Pledge (20 days of expected Block Reward at the time of activation) and at most 70 days of current daily Block Reward. For an old sector, the `BaseTerminationFee` will likely hit the capped level of 70 days of Block Reward at activation, meaning that this requirement implies **a current daily Block Reward that is about 25 times larger than the activation daily Block Reward**. Note that in this event **there would be a risk that a Storage Provider will not have enough collateral** available to pay Termination Fee. This risk is partially mitigated by the existence of the [Consensus Pledge](/gBgRMGiZSf25JyyDi9SyTw) 4. Although the Termination Fee is generally expected to be payable for _new_ sectors the risk that the Storage Provider does not have enough collateral available to pay the Fee _increases_ as the sector gets older. This is because the expected rewards at the time of activation tends to be higher than the actual rewards as time goes on. This risk is partially mitigated by the existence of the [Consensus Pledge](/gBgRMGiZSf25JyyDi9SyTw) ## The Story of the Termination Fee ### The Initial Proposal :::success ok ::: The Termination Fee was initially proposed around April 2020 and its form was defined as: - `TerminationFee[t] := max(StoragePledge[t], BaseTerminationFee[t])` - `BaseTerminationFee[t] := InitialPledge * (1 + min[Sector Age / 20 Days, 9 Days])` One limiting factor at that time was how much data was actually accessible and thus usable to condition upon within the Termination Fee. Computing the Locked Rewards associated a sector was not a trivial technical operation, and so the formulation of the Termination Fee required an assumption regarding how much collateral a Storage Provider would have. In addition, this early form of the Termination Fee would be triggered when a sector was in a Faulty state for "14 consecutive proving periods" rather than the current implementation's duration of 42 consecutive days. Thus, the 'slack' that would have existed between the Faulty state duration of 14 'proving periods' and the Storage Pledge provision (20 days' worth of Block Reward) paid out in the event of termination is no longer present with the longer Faulty state termination threshold of 42 days. Specifically, 14 days of faulty periods would generate an penalty of ~31.5 worth of Block Reward, while 42 days will generate an penalty of ~91.4 days' worth of Block Reward _Excerpt from April 2020_ <kbd>![Termination Fee per Sector Definition on the Slash the World document](https://hackmd.io/_uploads/SJZvWS8dj.png) ![](https://hackmd.io/_uploads/HywS1_D_s.png)</kbd> ### The Evolution of the Fee An initial modeling concern was related to the rationality of recovering sectors in the event of Faults. Between the time of this initial round of design, preliminary implmentation on Testnet and final recommendations for Mainnet (cf. the figure below), the functional form of the Fee went through several iterations: - Initial Design:`TerminationFee[t] := max(SectorPenalization[t], BaseTerminationFee[t])` - Prior to Testnet: - `BaseTerminationFee[t] = InitialPledge + BlockReward(t_start) * min[Sector Age, 180 days]` - `SectorPenalization: 5 days of Sector BR at Penalty Time` - Post Testnet Recommendations: - `BaseTerminationFee[t] = BlockReward(t_start) * (20 + min[Sector Age, 70 days])` - `SectorPenalization: 5 days of Sector BR at Penalty Time` - Mainnet Recommendations - `BaseTerminationFee[t] = BlockReward(t_start) * (20 + min[0.5 * Sector Age, 70 days])` - `SectorPenalization: 3.5 days of Sector BR at Penalty Time` _Filecoin Cryptoeconomics Recommendations, June to September 2020._ ![](https://hackmd.io/_uploads/HkSHGB8ds.png) ___ In September 2021 (and as described above), there was a [network update](https://github.com/filecoin-project/community/discussions/74#discussioncomment-1398542) implemented via [FIP-0026](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0026.md) that increased the number of consecutive days in a Faulty state required for sector termination from 14 days to 42 days. Upgrading the Termination Fee was also considered during the development of Filecoin Improvement Proposals (FIPs) 17 and 19, and some discussion from that time may also be found in the [Qualitative Analysis, FIP 17/FIP 19](/t69zej6-Td6OfKW_WgUbkQ), the [Meso Research Plan for the Termination Fee](/uhwH00C1SB6u_W3Ar-TIdw) and the [Termination fee governance surface and functional form](/bZr6bPMXQa-Vm3867SdTgg) research documents, undertaken by BlockScience and Protocol Labs' CryptoEconLab (CEL) Team over the course of 2021 and 2022. ## The Future of the Termination Fee :::success ok ::: The Termination Fee has an intimate connection with (at the time of this writing) proposed changes to the protocol involving the quality adjustment factor applied to sectors. In brief, the Sector Duration Multiplier (SDM) vs. Capped Duration Multiplier (CDM) debate (cf. [discussions](https://github.com/filecoin-project/FIPs/discussions/554) regarding [Filecoin Improvement Proposal (FIP) 0056](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0056.md) and the associated [superset proposal discussion](https://github.com/filecoin-project/FIPs/discussions/636)) concerns how the inclusion of a sector's duration into rewards impacts the ecosystem. While not delving into the details of whether or not a multiplier to sector duration should be capped, both sides of this debate have also proposed changes to the Termination Fee. These changes generally increase the Fee beyond expected Block Rewards, by allowing the sector duration multiplier to adjust the `CappedSectorAge` significantly upwards. The rationale here is simply that since rewards are scaled upwards by the sector duration multiplier, so too should the Fees associated with termination. BlockScience has, in [its analysis of the SDM vs. CDM debate](https://medium.com/block-science/reviewing-the-fip-0056-and-cdm-debate-on-filecoin-6a6af0ed4b78#4aa6), suggested that the proposed changes in the Termination Fee be distilled and moved to a _separate_ FIP. This is because the changes proposed can (in the case of e.g. CDM) run _counter_ to the desired incentives, by making termination extremely expensive in the long term and thus penalizing a longer sector duration. This is primarily a failure to incorporate an _opportunity cost_ view of the decision of whether or not to terminate a sector. ___ At this point in time it is unclear if an adjustment to the Termination Fee can support the intended incentives arising from the implementation of a sector duration multiplier directly into the existing functional form discussed above. Instead of implementing changes to the Termination Fee in piecemeal fashion, a 'back-to-basics' approach is advocated in which the recommended examination of the functional form for the solution the sector duration multiplier is designed to address is accompanied by a functional form examination of the Termination Fee. This _systems approach_ to the problem ensures that incentives remain aligned within the solution space of the design, rather than perhaps reinforcing countervailing incentives and hence weakening the expected benefits of both solutions. While a form of the Termination Fee is expected to always be present within the Filecoin ecosystem, its reflection of the opportunity cost of terminating a sector, i.e .the expected benefit to a Storage Provider of the next best use of the (terminated) sector, would appear to be a _minimal necessary condition_ for the Termination Fee to possess. Coupled with the overall objective of adjustments such as changes to sector duration returns (via e.g. the sector duration multplier), utilizing the systems perspective and building upward from minimal necessary conditions can provide an internally-consistent grounding of the Termination Fee that, thus designed, supports Filecoin's overall system objectives. ## Conclusion :::success ok ::: The overall objective of the Termination Fee is to dissuade Storage Providers from terminating sectors, whether by actively choosing termination or by passively allowing faults to accumulate until the protocol terminates the sector. As such, it acts as the 'stick' that accompanies the 'carrot' of Block Rewards earned throughout the lifetime of a sector provided to the network. As described above, this is because the `SectorPenalization` is almost always outweighed by the `BaseTerminationFee`. Historically the form of the Termination Fee has evolved to address these multiple incentive pathways (active vs. passive), and the recent debate on the sector multiplier continues this evolution. This is a healthy state of development---our recommendation is that this development continues to proceed along a _systems integration_ path, by examining the types of dependences upon e.g. sector age/duration, expected Block Rewards, Sector Pledges etc. that are consistent with the sector reward structure, since this latter structure is based also upon expected Block Rewards, realized Block Rewards and Sector Pledges. By breaking apart the Termination Fee into its constituent components, examining scenarios, and providing its 'backstory' we hope that this article has served to help clarify the Fee's foundations. At the same time, we hope the discussion of its future has also shed light on its complex dependencies, and how it cannot readily be designed 'in a vacuum' without understanding its role in the overall incentive mechanism governing the provision of storage to the Filecoin ecosystem. ## Resources - Filecoin Specification - [Cryptoeconomics](https://spec.filecoin.io/algorithms/cryptoecon/) - [Faults and Termination](https://spec.filecoin.io/systems/filecoin_mining/sector/sector-faults/) - [Slashing](https://docs.filecoin.io/storage-provider/rewards/slashing/) - Source Code definitions - [Fee Calculation](https://github.com/filecoin-project/specs-actors/blob/d8d9867f68a3c299295efdc6d1b3421c9b63df57/actors/builtin/miner/monies.go#L117) - [Penalty Processing](https://github.com/filecoin-project/specs-actors/blob/3c87d38a4829460c92a084465521f649d7613796/actors/builtin/miner/miner_actor.go#L2406) - Notes on Termination Fee - [Meso Research Plan for Termination Fee](/uhwH00C1SB6u_W3Ar-TIdw) - [CEL Termination Fee Analysis](/StZutrKxQ-ajF7kuR4b0LA) - [Termination fee governance surface and functional form](/bZr6bPMXQa-Vm3867SdTgg) - [Reviewing Termination Fee](/nLNuwnjPQn6CGsN_XtgSbg) - [Protocol Workshops Notes](https://docs.google.com/document/d/1G8X-EzCcXhtqFz6g7bx_3uRKVZ-xYYS1wlUL6XZxQxs/edit)