Ensuring Sector Permanence in the Network
This work is part of a series on Filecoin Core Protocol Review that was inspired by conversations between BlockScience and CryptoEconLab. The goal is to dive into the historical and design context around the decisions and developments in Filecoin Economics, with this article focusing on the Termination Fee and our previous article focusing on the Consensus Pledge.
Introduction
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 in the network, and a protocol incentive structure to ensure such availability. This combination balances the two types of inputs in a way that is designed to maximize the likelihood that the ecosystem can rely upon storage that is both error-free and dependable at least up to the time of sector expiration.
What is the Termination Fee?
According to the Filecoin Spec, 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:
- 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 availability, and the Termination Fee must be paid by the storage provider.
- 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 availability, 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. These combinations may be broken down as follows:
- 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 if the current age of the to-be-terminated sector isSectorAge,
2. For each day in the sector’s age, up to the CappedSectorAge, the estimated block reward ExpectedDailyRewards is assessed (this is computed elsewhere in the protocol), and the total is then discounted by 50%. The result is the CappedExpectedEarntRewards, to be assessed as part of the Fee:
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:
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.5 days of expected sector rewards), and make up the SectorPenalization:
5. Finally, the protocol selects the maximum of the BaseTerminationFee and the SectorPenalization, to arrive at the TerminationFee:
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.5 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 Quality Adjusted Power (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 from 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
It can be helpful to understand the Termination Fee functional form given the 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 contrast in ‘Scenario 2’ block rewards increase to 10 FIL daily from Day 10 (the initialization date of the sector) to Day 30, and returns 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 below, 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, the 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 tend to be larger than the Termination Fee, except in the very beginning of it — in Scenario 1, the Termination Fee becomes smaller than the Earnt Rewards after 40 days.
Termination Fee when Upgrading a Sector
When a Sector is upgraded, the Expected Daily Rewards change. In order to take that into account, the Termination Fee takes a different shape with old sectors. The Base Termination Fee will depend instead on the RelevantExpectedEarntRewards, which is defined as:
The Replaced Expected Earnt Rewards represent how much was earned before the upgrade up to a limit. The reason for this design is to disallow sectors to take advantage of a reduced Termination Fee when upgrading. The following table and illustration demonstrate 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 it is newer than the cap, then the Fee can go up for a duration and then go down.
Challenges and Risks Associated with the Termination Fee
As of this writing, there are differences between what is communicated in the Filecoin Specification 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 dependencies between the Fee and other components of the Filecoin ecosystem.
Examples of such interactions include:
- Updates to Filecoin Network’s Economics have not always integrated a general systems perspective, leading to piecemeal updates of one component without corresponding changes to other components. For example, the period of observation for consecutive days of faults increased to 6 weeks 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.
- The Termination Fee has multiple dependencies 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), we can expect the sector Storage Pledge and expected daily rewards for a sector being onboarded or upgraded to go down over time. - The Termination Fee can depend upon the sector Expected Rewards at the time of termination (currently 3.5 days of the expected sector Block Reward). However, this dependency should be considered as rare for ‘mature’ sectors, since it would require that
SectorPenalizationexceeds theBaseTerminationFee, i.e. that the 3.5 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, theBaseTerminationFeewill 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 c. 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. - 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 tend to be higher than the actual rewards as time goes on. This risk is partially mitigated by the existence of the Consensus Pledge.
The Story of the Termination Fee
The Initial Proposal
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 calculate the Termination Fee. Computing the Locked Rewards associated with 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 a penalty of ~31.5 days’ worth of Block Reward, while 42 days will generate a penalty of ~91.4 days’ worth of Block Reward.
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 implementation 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
In September 2021 (and as described above), there was a network update implemented via FIP-0026 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, the Meso Research Plan for the Termination Fee and the Termination fee governance surface and functional form research documents, undertaken by BlockScience and Protocol Labs’ CryptoEconLab (CEL) Team over the course of 2021 and 2022.
The Future of the Termination Fee
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 regarding Filecoin Improvement Proposal (FIP) 0056 and the associated superset proposal discussion) 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, 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 multiplier), 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
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 dependencies 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.
This article was written by Danilo Lessa Bernardineli and Jamsheed Shorish with special thanks to Hashir Nabi, Jeff Emmett, and Jessica Zartler for editing and publication.
Resources
Filecoin Specification
Source Code definitions
Notes on Termination Fee
- Meso Research Plan for Termination Fee
- CEL Termination Fee Analysis
- Termination fee governance surface and functional form
- Reviewing Termination Fee
- Protocol Workshops Notes
About BlockScience
BlockScience® is a complex systems engineering, R&D, and analytics firm. By integrating ethnography, applied mathematics, and computational science, we analyze and design safe and resilient socio-technical systems. With deep expertise in Market Design, Distributed Systems, and AI, we provide engineering, design, and analytics services to a wide range of clients including for-profit, non-profit, academic, and government organizations.
