# Describing Filecoin's Cryptoecon Mechanisms Goals, Expected Behaviour and KPIs

###### tags: `Research`

:::info
Up to date by December 2022
:::

*Authors: Danilo Lessa Bernardineli (BlockScience), Jakob Hackel (BlockScience), Jamsheed Shorish (BlockScience)*

## Summary

This document is a straightforward description of the main economic levers, or _mechanisms_, of Filecoin at both the microfoundation and macroeconomic levels. The description includes both mechanism goals and how these goals can be benchmarked in light of *counterfactual* scenarios, which help to answer the query, "what would happen if we didn't have those mechanisms in place?"

Using this approach we aim to provide clarity on the rationale for the implementation of the associated mechanisms, as well as to provide directions on how to measure if the intended goal(s) of each mechanism is/are achieved, i.e. if they are _successful_.

Lastly, we contextualize this document as a _scoping exercise_ for implementing **Initiative 1** as described in the [Surfacing High Impact Cryptoeconomics Research Topics on Filecoin on 2022](/2tvTsUquSzSUytv2M2dtFA) report.

___

*Figure: An ill-fated attempt at diagramming out all the Cryptoecon components and interactions on Filecoin, indicating the usefulness of performing a mechanism-by-mechanism breakdown. [(Source)](https://kumu.io/danlessa/filecoin-vision)*

## Mechanism Success and the Cryptoeconomics of the Filecoin Ecosystem

In order to be precise about what is meant by a 'successful' mechanism, a definition of _success_ should be provided and, it is hoped, agreed-upon by ecosystem stakeholders. In order to create such a definition for a particular mechanism, the mechanism itself should describe:
1. its _intention_, i.e. what it has been designed to accomplish, and
2. its _realization_, i.e. what it has actually accomplished during its implementation.

From these descriptions, a mechanism's individual measure of success is how closely realization 'matches' or 'achieves' intention. By creating measures for intention and realization for a given mechanism, a quantitative comparison can be made, and a resulting 'success metric' generated.

In general, the intention of a given mechanism is not necessarily a representation of its success within the context of the ecosystem, as its intended behavior is usually in reference to (and may depend upon) the intended behaviors of other mechanisms. Thus, the intention of a mechanism is part of a larger set of Design Goals that encompass the overall ecosystem. Once success metrics have been derived for individual mechanisms, their contribution to the overall Design Goals can be (usually qualitatively) assessed, and a governance process used to achieve stakeholder consensus on whether the Design Goal contribution has met or exceeded a desired minimum threshold.

In this way, there are two governance-implemented ecosystem adjustments that success metrics may facilitate (or "trigger"), depending upon their values:
1. a _mechanism-level adjustment_, that may be necessary when a mechanism's individual success metric falls short of a minimum required threshold; and
2. a _subsystem-level adjustment_, that may be necessary when a mechanism's contribution to the overall Design Goals is less than desired (or required).

Note that in principle a subsystem-level adjustment could occur even if an individual success metric is above its minimum threshold, as (for example) if the existing mechanism's individual success is satisfactory, but is "swamped" by detrimental externalities from other parts of its subsystem (or from interfaces between subsystems) that result in a failure to support the Design Goals. But for the most part one would expect that at least a sufficient condition for a subsystem-level adjustment is that a mechanism-level adjustment has already been deemed necessary.

What follows is a comprehensive breakdown of the Filecoin cryptoecon mechanisms, into Sections focusing on different subsystems within the overall ecosystem. Each mechanism (occupying a Subsection) described below contains the following information (sometimes preceded by figures/graphs where deemed helpful):

- _What It Is_: 1-4 lines on what it does, and with what (or with whom) it interacts.
- _Design Goals_: The rationale for implementing it as well as any goals that were used for tuning / validation.
- _Expected Behaviour_: A list or paragraph describing how it responds under "steady-state" conditions, and in perceived edge cases.
- _Benchmarks_: A list of (meaning, KPI, metric, counterfactual scenario) combinations that can be used for understanding if the mechanism was historically sucessful in delivering its intended goals.
- The counterfactual scenarios described in this document will avoid using any kind of behavioural modelling, which can be hard to validate empirically and requires an elaborate set of assumptions. As much as possible, we want to provide direct cause & effect answers to "what would happen if we didn't have this mechanism?" types of questions, while minimizing the required context.

## Sector Dynamics

___
### Reward Locking

*Total and Daily changes on the Locked / Mined Supply. [(Source: Filecoin Network Health Dashboard - Circulating Supply, Starboard Ventures)](https://dashboard.starboard.ventures/circulating-supply)*

**What It Is**: When a Miner wins a Block Reward, this reward is locked and vested sublinearly for a period of time and it is tracked per-miner, as tracking per-sector is infeasible.

**Design Goals**
1. Making Dropping Sectors Economically Irrational
2. Reducing Onboarding Collateral Requirements for Miners

**Expected Behaviour**
- The amount of Total Locked Rewards should increase quickly in the first 6 months after launch, increase steadily until a point near the first Baseline Crossing from below, and decrease steadily afterwards.
- Most of the Termination Fees should be covered by the Locked Rewards
- It is expected that the Locked Rewards associated with a sector should be higher than the Storage Pledge by a significant amount

**Benchmarks**

- Storage Pledge Subsidy Index
- Meaning: Indicates by how many times the storage pledge was "effectively" increased because of the Locked Rewards Mechanism. (eg. 'by how much would we need to increase the Storage Pledge if we didn't lock the rewards?')
- Metric: Sum of `[LockedRewards(t; S) + StoragePledge(t; s)] / StoragePledge(t; S)` over the Sector Dimension, Average over the Time Dimension
- Counterfactual Scenario: A historical evolution of the network during which Miner rewards are made free immediately. All other variables can be assumed to remain the same (InitialPledge etc.)
- Termination Fee Cover Index
- Meaning: Indicates by how many times the buffer for the network to pay the termination fees was increased because of the Locked Rewards Mechanism.
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Sum of `[LockedRewards(t; S) + InitialPledge(t; s)] / Termination Fee(t; S)` over the Sector Dimension, Average over the Time Dimension
- Counterfactual Scenario: A historical evolution of the network during which Miner rewards are made free immediately. All other variables can be assumed to remain the same (InitialPledge etc.)
- Average Marginal Locked Supply
- Meaning: Indicates by how many times the Locked Supply was increased on average because of locking rewards vs freeing them immediately
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Sum of `Locked Supply(t)` over the Time Dimension
- Counterfactual Scenario: A historical evolution of the network during which Miner rewards are made free immediately. All other variables can be assumed to remain the same (InitialPledge etc.)

___
### Storage Pledge

*Collateral and Locked Rewards Composition of the Locked Supply Over Time: [(link](https://docs.google.com/spreadsheets/d/1-1z5q3CPpUaOieoycEgpFG_SD7LZjlV4DiKu4BfROns/edit#gid=1265414632))*

**What It Is**: Storage Pledge is a required Miner Collateral that provides security against faults and penalties. Currently set to 20 days of estimated block rewards (*source: [Filecoin Specification](https://spec.filecoin.io/#section-systems.filecoin_mining.miner_collaterals)*). Protocol Review notes can be found at [Reviewing Termination Fee](/nLNuwnjPQn6CGsN_XtgSbg).

**Design Goals**
1. Ensuring a minimum slashable amount per Sector.
2. Small enough not to disincentivize miners from joining, but large enough to collateralize against early faults, penalties and fees

**Expected Behaviour**
- Secure clients against early faults, penalties and fees for miners
- Be worth 20 days of expected block rewards, which is roughly enough to cover 7 days worth of Sector fault fees and 1 Sector fault detection fee

**Benchmarks**

- Sector Solvency Index
- Meaning: Measures how much the Storage Pledge is contributing to the network capacity to be solvent in terms of Fees and Penalties.
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Average of `SectorSolvencyIndex(t) = Relative Penalty Index(t) / (AverageSectorQAP(t) * NetworkQAP(t) / LockedSupply(t))` over the Time Dimension
- `Relative Penalty Index(t) = Rolling Weekly Sum of (Fault + Penalty + Termination) Fees / Rolling Weekly Average of (Circulating + Locked) Supply`
- Counterfactual Scenario: A historical evolution of the collateralization available with respect to the actual collateral that was needed during which Miners weren't required to lock-up the Storage Pledge. All other variables can be assumed to remain the same (ICP, Deal Collateral)
- Change in the Collateral available
- Meaning: Explains how much relative increase in the Collateral Supply can be attributed to the Storage Pledge
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Average of `Initial Pledge(t)` over the Time Dimension
- Counterfactual Scenario: A historical evolution of the network during which Miners weren't required to lock-up the Storage Pledge. All other variables can be assumed to remain the same (ICP, Deal Collateral)
- Change in the Cost of Onboarding a Sector
- Meaning: Measures how much the Storage Pledge is increasing the Capital Costs of onboarding a Sector
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Average of `Initial Pledge(t) * Daily FIL Price (t) / NetworkQAP(t)` over the Time Dimension
- Counterfactual Scenario: A historical evolution of the capital cost to onboard a sector during which Miners weren't required to lock-up the Storage Pledge. All other variables can be assumed to remain the same (ICP, Deal Collateral)

___
### Consensus Pledge


*Collateral Share of the Locked Supply Over Time: Source: [(link](https://docs.google.com/spreadsheets/d/1-1z5q3CPpUaOieoycEgpFG_SD7LZjlV4DiKu4BfROns/edit#gid=1265414632))*

**What It Is**: Consensus Pledge is a required Miner Collateral that induces direct Token Economy effects because of its reliance on Circulating Supply. It is expressed by the formula:
$$ICP(t) = TargetLockedSupply * CirculatingSupply(t) * \frac{SectorQAP}{max(BaselinePower(t), NetworkQAPEstimate(t))}.$$
Protocol Review notes can be found at [Reviewing the Target Locked Supply](/90MrWid8QHejWGAju9EaDw).

**Design Goals**
1. Increasing economic costs of Consensus Attacks from outsiders
2. Having a direct incentive feedback between Circulating Supply and QAP Change Rates
3. Increasing the available buffer for faults and slashes

**Expected Behaviour**

- The higher the $CirculatingSupply/NetworkQAP$ ratio, the more someone should lock-up for onboarding a new sector
- For a fixed network QAP and Circulating Supply, the Consesus Pledge should go down when crossing baseline down.
- Should interact synergistically with the FIL price for increasing the Capital Costs of network take-over
- The Consensus Pledge feedbacks on the Baseline, Circulating Supply and the Network QAP simultaneously, and as such, it depends on the evolution of several non-linear / stochastic functions. This makes the actual dynamics of it non-trivial, and simulations can be required in order to understand the exact behaviour.

**Benchmarks**

- Change in the Cost to Upgrade to 33% of the Network QAP
- Meaning: Indicates by how many times it would be more expensive to perform a sudden 33% QAP upgrade attack. This is a useful proxy to measure the marginal increase in network security due to the introduction of the Consensus Pledge.
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Time Average of `(Initial Pledge(t) * 33% of the NetworkQAP(t) / NetworkQAP(t) + Gas Costs(t)) * FIL Price(t)`
- Counterfactual Scenario: A historical evolution of the network during which Miners weren't required to lock-up the Consensus Pledge. All other variables can be assumed to remain the same (Onboarding, FIL Price, etc)
- Change in the Circulating Supply
- Meaning: Indicates by how many times the Circulating Supply went up or down because of the Consensus Pledge
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Sum of `Circulating Supply(t)` over time
- Counterfactual Scenario: A historical evolution of the network during which Miners weren't required to lock-up the Consensus Pledge. All other variables can be assumed to remain the same (Onboarding, FIL Price, etc)
- Change in Total Locked Supply
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Average of `LockedSupply(t)` over the Time Dimension
- Counterfactual Scenario: A historical evolution of the network during which Miners weren't required to lock-up the Consensus Pledge. All other variables can be assumed to remain the same (Onboarding, FIL Price, etc)

___
### Quality Ajusted Power

*Raw-Bytes and Quality-Adjusted Storage Capacity Over Time. [(Source: Filecoin Network Health Dashboard - Capacity & Services, Starboard Ventures)](https://dashboard.starboard.ventures/circulating-supply)*

**What It Is**: For the purposes of Reward Allocations and Miner Collaterals, there is a notion of a "Quality-Adjusted" Power, which is the Actual Storage Capacity (or Raw-Bytes) multiplied by a Quality Adjustment Factor associated with a given sector. As of now, this multiplier is defined as being 1x for Committed Capacity Storage, 1.1x for Storage associated with Regular Deals, and 10x for Storage associated with FIL+ Deals. This can change in the near future with the possible introduction of mechanisms like the [Sector Duration Multiplier](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0036.md).

**Design Goals**

- Incentivize forms of storage that are deemed useful to the ecosystem
- Differentiate Consensus Power (associated with the share of rewards, the skin in the game and rights) from Storage Capacity (the raw storage available)

**Expected Behaviour**

- The ratio between QAP and RBP should increase over time, eventually converging close to the Maximum Quality Adjustment Factor.
- Activities that do not take advantage of the QAP factor can become unprofitable relatively fast due to the waning share of rewards.
- Increased QAP over RBP dominance can be associated with increased network security, as upgrading over CC sectors represents a direct pathway to acquire an outsized share of the Consensus Power without being directly limited by onboarding rates or hardware costs.

**Benchmarks**

- QA-induced Network Security Index
- Meaning: Proxies by how many times acquiring shares of the network became more capital expensive because of the QA factor
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Average of `New Sector Initial Pledge(t) * FIL Price(t) / NetworkQAP(t)` Over Time
- Counterfactual Scenario: Historical Evolution during which all QA factors are set to 1x
- QA-induced Collateral Premium Index
- Meaning: Indicates by how many times the Initial Pledge was increased because of the QA factor
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Sum of `New Initial Pledge(t)` over Time
- Counterfactual Scenario: Historical Evolution during which all QA factors are set to 1x

## Slashing Dynamics

___
### Fault Fees

*Daily New Faults & Average Faulty Days Over Time. [(Source: Filecoin Network Health Dashboard - Capacity & Services, Starboard Ventures)](https://dashboard.starboard.ventures/circulating-supply)*

**What It Is**: Fault Fee is a daily amount that accrues on the Miner Debt while a sector is faulty. There's a grace period of 1 day and it is defined (as of now) as being 2.14x the amount of the daily reward that the sector would obtain if active. The Sector will be automatically terminated if it is faulty for 42 consecutive days. [(Source)](https://spec.filecoin.io/systems/filecoin_mining/sector/sector-faults/)

**Design Goals**

- Incentivize Miners to have a reliable storage capacity
- Incentivize Miners to recover faulty sectors as quickly as possible
- Additional guarantees on data availability for clients

**Expected Behaviour**

- It is hypothetically possible that the maximum accruable debt per sector is larger than the associated collateral (eg. `42 days of fault fees + termination fee + sector penalty > initial pledge + accrued rewards`). This is mainly a risk with the new sectors / new miners combination.
- Miners with a large number of sectors can be especially disincentivized from incurring Fault Fees, as the Maximum Debt Accruable per Sector can be larger than the Initial Pledge per Sector

**Benchmarks**

- Fault Fee Debt Index
- Meaning: Indicates by how much % the Maximum Accruable Sector Debt can be associated with Fault Fees.
- KPI: `1 - (Counterfactual Metric / Historical Metric)`
- Metric: Average of `MaximumAccruableDebt(t)` over the Time Dimension
- `MaxAccruableDebt(t) = Sum Over Sectors of [42d of FaultFee(t; S) + SectorPenalty(t; S) + TerminationFee(t; S)]`
- Counterfactual Scenario: A scenario where Fault Fees are defined as being Zero.
- Aggregate Resilency to Faults Index
- Meaning: Indicates how much % additional buffer there is on the real world scenario when compared to a situation in which 1 Sector = 1 Miner.
- KPI: `(Historical Metric / Counterfactual Metric) - 1`
- Metric: Average of `MaximumAccruableMinerDebt(t; M) / MinerLockedFunds(t; M)` over the Time Dimension and the Miner Dimension
- `MaxAccruableMinerDebt(t; M) = Sum Over Miner Sectors of [42d of FaultFee(t; S_M) + SectorPenalty(t; S_M) + TerminationFee(t; S_M)]`
- Counterfactual Scenario: A scenario where each sector is an individual Miner (rather than Miners having multiple sectors)

___
### Termination Fees

*Terminated Power Over Time. [(Source: Filecoin Network Health Dashboard - Capacity & Services, Starboard Ventures)](https://dashboard.starboard.ventures/circulating-supply)*

**What It Is**: Termination Fee is accrued when a sector is terminated before expiration, either after 42 days of faults or by the Miner themselves. It roughly tracks the earned sector rewards. Protocol Review notes can be found at [Review on Termination Fee](/nLNuwnjPQn6CGsN_XtgSbg).

**Design Goals**
- Incentivize miners to keep sectors active for the full duration
- Provide clients with certain guarantees on data availability
- Allow miners to terminate sectors when required to do so without forcing them to incur the maximum achievable debt per sector.

**Expected Behaviour**

- Termination Fees are likely to be incurred as a way of avoiding excessive Fault Fees when terminating a sector or during shock events.
- Old sectors are likely to have higher termination fees than new sectors. Combined with the fact that larger miners tends to have a larger locked funds pools, it is likely that new miners will be more pro-active in terminating sectors.

**Benchmarks**

- Active Termination Rationality Index
- Meaning: How much FIL was saved for Miners because the network allows for Active Termination rather than only Passive Termination
- KPI: `Counterfactual Metric - Historical Metric`
- Metric: `Sum of Daily Acrued Debt(t)` over Time
- Counterfactual Scenario: Historical evolution during which all Active Terminations would have paid instead the Maximum Accruable Sector Debt (Sector Penalty + Maximum # of Fault Fees + Termination Fee) rather than the Actual Accrued Sector Debt.
- Termination Generosity Index
- Meaning: By how many times the Termination Fee would be higher/lower if it was set up to burn all the locked rewards instead
- KPI: `Counterfactual Metric / Historical Metric`
- Metric: Sum of `Termination Fee(t; S)` over Sectors and over Time
- Counterfactual Scenario: Historical evolution during which the Termination Fee is set to be the full associated Locked Rewards with the sectors + the Sector Storage Pledge.

___
### Sector Penalties

*Daily Passive Terminations Over Time. [(Source: Filecoin Network Health Dashboard - Capacity & Services, Starboard Ventures)](https://dashboard.starboard.ventures/circulating-supply)*

**What It Is**: A fee that should be paid when a sector is detected to be faulty by the system, rather than declared faulty by the miner themselves. Also known as Passive Faults (as compared to Active Faults).

**Design Goals**
- Incentivize miners to declare faulty sectors early to reduce unannounced service disruption
- Disincentivize miners trying to earn block rewards without being detected while they already know their sector is faulty

**Expected Behaviour**
- Should be more common with irrational actors / out of control shock events.
- One heuristic is that it should be more heavily associated with smaller miners and/or sudden events, like censorship events.

**Benchmarks**

- Detection Burden Index
- Meaning: Indicates the share of the total Miner Fee Debt that is associated with network detection of faults.
- KPI: `(Historical Metric - Counterfactual Metric) / Historical Metric`
- Metric: Sum of `Daily Acrued Debt(t)` over Time
- Counterfactual Scenario: Historical evolution during which Sector Penalty is set to Zero.

___
### Consensus Penalties

*Illustration of the Double-Fork Mining Fault*

**What It Is**: A Consensus Fault happens when a Miner deviates from the Protocol and is reported by a Detecting Miner for signing two blocks. A single consensus fault will terminate the miner and remove all his power from the power table. All the Initial Pledge and the Locked Rewards will also be slashed. A portion of the slashed amount will be awarded to the first reporter and is exponentially increasing, conditional on the time elapsed from detection since the fault commit. Types of Consensus Faults include the Double-Fork Mining Fault, Time-Offset Mining Fault and the Parent-Grinding Fault.
[(Source: Filecoin Spec 4.1.6 - Consensus Faults)](https://spec.filecoin.io/#section-algorithms.expected_consensus.consensus-faults)

**Design Goals**
- Penalize Consensus Attacks
- Do not penalize incorrectly built single blocks
- Only penalize when two blocks are submitted by one miner, with valid signatures, for any of these three scenarios:
- 1. Double-Fork Mining Fault: two blocks mined at the same epoch (even if they have the same tipset).
- 2. Time-Offset Mining Fault: two blocks mined off of the same Tipset at different epochs.
- 3. Parent-Grinding Fault: one block’s parent is a Tipset that provably should have included a given block but does not.
- Incentivize discovery and reporting of faults

**Expected Behaviour**
- Entire pledge collateral slashed (initial pledge and blocks rewards yet to be vested)
- Terminate miner and remove power from power table
- Only penalized if fault is proven
- Slashing Reward:
- Portion of slashed pledge collateral paid to whoever reports the consensus fault first
- Function of initial share, growth rate, but capped at a maximum share
- Increases exponentially with each epoch since fault was committed
- Waiting to report consensus fault increases chance that somebody else claims reward
- Remainder of slashed pledge collateral is burned

**Benchmarks**

- Average Bonus on Awards because of Detection Delays
- KPI: `Historical Metric / Counterfactual Metric `
- Metric: Sum on `Daily Consensus Penalties(t) - Daily Burnt FIL(t)` over the Time Dimension
- Counterfactual Scenario: A historical evolution of the network during which Consensus Faults would be have been detected immediatly.
- Total FIL awarded to Watchful Miners
- Meaning: How many FIL token were distributed from malicious actors towards reporting miners
- KPI: `Historical Metric - Counterfactual Metric`
- Metric: Sum on `Daily Consensus Penalties(t) - Daily Burnt FIL(t)` over the Time Dimension
- Counterfactual Scenario: A historical evolution of the network during which the Consensus Penalty is set as Zero.
- Total FIL burnt from Malicious Actors
- Meaning: How many FIL tokens were burnt because of malicious attempts to manipulate the Network Consensus
- KPI: `Historical Metric - Counterfactual Metric`
- Metric: Sum on `Daily Burnt FIL(t)` over the Time Dimension
- Counterfactual Scenario: A historical evolution of the network during which the Consensus Penalty is set as Zero.

## Token Dynamics

___
### Supply Composition

**What It Is**: The allocation of the Filecoin token ("FIL") may be classified according to whether an existing holder possesses a portion of an initial token issuance, or whether the protocol itself issues ("mints") new tokens to new and/or existing holders to fulfil ecosystem objectives. The latter class represents the Storage Mining Allocation and (possibly) the Mining Reserve, while the former class is represented by all other allocations.

*Source: [Filecoin Specification](https://spec.filecoin.io/#section-systems.filecoin_token.token_allocation)*

**Design Goals**
1. Storage Mining Allocation: Provide the means to incentivize storage provider behavior, using mining rewards and slashing penalties; provide the means for storage providers to pay costs associated with the provision of storage, such as collateral costs, proof message gas costs, etc.
2. Mining Reserve: Provide the means for stakeholders to adjust the incentive mechanism of the Storge Mining Allocation in the future, via governance.
3. SAFT Holdings: Initial investors who participated in the Simple Agreement for Future Tokens issuance are provided the means to bootstrap token liquidity in e.g. secondary markets, storage provision, storage (deal) purchasing, etc.
4. Filecoin Foundation (FF): Provides the means for the Foundation to engage in e.g. market operations as stakeholders warrant for the health of the ecosystem.
5. Protocol Labs (PL): Provides the means for incentivizing development of the Filecoin ecosystem, through both initial ecosystem creation and also through grants provided to third parties for future ecosystem developement and improvement.

**Expected Behaviour**

There will be a gradual (continuous or discrete) outflow of each stock towards the Circulating Supply. Specifically:

- Storage Mining Allocation should be disbursed continuously and slow down over time;
- Mining Reserves should be disbursed through a mix of discrete and continuous events (2-year frequency scale), and the share of the available reserve being disbursed should be relatively constant over time;
- SAFT Holdings should be disbursed continuously, mainly after the vesting events, and slow down over time;
- Filecoin Foundation: will disburse at mainly random discrete events, with a relatively high disbursement frequency (e.g. 1-month frequency scale);
- Protocol Labs: will disburse in a manner similiar to the Filecoin Foundation.

**Benchmarks**

- SAFT Holdings / FF / PL Contributions to the Circulating Supply
- Meaning: Indicates how much of the current circulating supply is explained by the presence of the SAFT / FF / PL holdings.
- KPI: `Historical Metric / Counterfactual Metric - 1`
- Metric: Sum of `Delta Circulating Supply(t)` over time
- Counterfactual Scenario: Historical evolution with SAFT / FF / PL Supplies being set to zero

___
### Vesting Schedule

*Total and Daily changes on the Vesting Schedule Over Time, excl. Storage Mining Rewards. [(Source: Filecoin Network Health Dashboard - Circulating Supply, Starboard Ventures)](https://dashboard.starboard.ventures/circulating-supply)*

**What It Is**: For those FIL holders who have a part of the intial token issuance, as well as those who have been provided a portion of Filecoin minting as a storage mining allocation ("reward"), there are restrictions on the timing of ownership transfer and hence of potential disbursement of holdings. Generally, for these types of holders, there is a **gradual release ("vesting") of tokens over time**.

**Design Goals**

Vesting is designed as a method of incentivizing ecosystem participation, because:
1. FIL which has not been distributed, or "unlocked", via vesting are assessed a value only at FIL's future price upon vesting---this means that **the FIL holder strictly prefers a higher future price of the token, incentivizing future activity and/or support that increases ecosystem value** and hence FIL value;
2. **A gradual token release schedule places an upper bound on the magnitude and rate of conversion** of held FIL into other units of account (e.g. ETH, USD etc.), which reduces the resulting price volatility of FIL and hence the risk associated with holding (or acquiring) the token.

**Expected Behavior**

1. *Storage Mining Allocation*: Of the issuance allocated to storage providers, **75% is vested with a linear release schedule over 180 days**. This provides the means to secure a time interval during which locked reward (which can still be slashed) incentivizes valid storage over (at least) the 180-day period.
2. *SAFT Holdings*: Most SAFT holdings are vested **linearly over 3 years**, but **smaller portions vest linearly over 2 years, 1 year and 6 months**. This provides a means to 'gate' the exchange of the token for other assets, limiting downward price pressure and providing a long enough time horizon for alternative uses of the token to potentially become more attractive than liquidation.
3. *FF*: Holdings of the Foundation vest **linearly over 6 years**, which provides the means for ensuring a strong potential source of the token exists, without running the risk of immediate downward price pressure in the event of liquidation of token balances (cf. also SAFT Holdings).
4. *PL*: similar to FF, PL holdings vest **linearly for 6 years**.
5. *Third-Party Grantees*: ecosystem partners and collaborators receiving grants from FF and/or PL have holdings also vested **linearly for 6 years**, for the same reasons as SAFT, FF and PL holders.
6. *General*: **vesting serves the purpose of securing the initial growth of the network by providing (in principle) uncorrelated token balances that are unavailable to an attacker** seeking to accumulate a significant fraction (or majority) of token circulating supply.

**Benchmarks**: Performing Cause-Effect Analysis on Market Movements requires behavioral modeling that goes beyond the scope of the KPIs of this document.

___
### Baseline Function

*Filecoin Baseline Minting Educational Calculator. [Source](https://medium.com/block-science/a-cadcad-interactive-calculator-to-explore-minting-scenarios-in-filecoin-284009a2e941)*

**What It Is**: The Baseline Function defines a complementary reward schedule on top of simple minting. This additional reward is conditional on the network achieving a moving target of storage capacity through the notion of an "Effective Network Time". Protocol Review notes can be found at [Reviewing QAP Rebase](/9JHIQMEaQgqlepvMzUgXUw). A simple way of understanding this is to view Baseline Minting as generating a "savings account" when RBP is below the baseline.

**Design Goals**
1. Reduce Window of Opportunities for Outsized Gains during Shock Events
2. Increase Long Term Predictability of Mining Rewards
3. Enable Governance Steering on Reward Issuance After Launch
4. Providing Clear Signals to the Ecosystem for the Capacity Targets in the Near/Medium Future

**Expected Behaviour**
- Rewards over time should be distributed network-wide at a maximum rate when the Raw-Byte Power is above the Baseline, creating a zero-sum game between Storage Providers in terms of Rewards. When it's below, it becomes a positive-sum game: the network-wide minting rate increases as the network grows.
- This is a rough description. The actual dynamics are more complicated. We recommend reading the article on the [Baseline Educational Calculator](https://medium.com/block-science/a-cadcad-interactive-calculator-to-explore-minting-scenarios-in-filecoin-284009a2e941) for greater intuition.

**Benchmarks**

- Baseline Function Shock Mitigation Index
- Meaning: How much of the Available Supply was roughly avoided being handed over from shock events because of Baseline Minting
- KPI: `(Counterfactual Metric - Historical Metric) / Current FIL Available SUpply`
- Metric: Sum of `Modified Daily Rewards(t)` over time
- `Modified Daily Rewards(t) = Daily Rewards(t) if DailyNetworkQAP(t) is below 80% of the WeeklyNetworkQAP(t) else 0`
- Counterfactual Scenario: Historical evolution with Baseline Function set to zero (eg. RBP is always above Baseline)
- Baseline Function Savings Index
- Meaning: How much FIL we have "stored" on the Baseline Minting Issuance as understood as a "Savings Account" as a fraction of the current FIL Available Supply
- KPI: `(Counterfactual Metric - Historical Metric) / Current FIL Available Supply`
- Metric: Sum of `Daily Rewards(t)` over time
- Counterfactual Scenario: Historical evolution with Baseline Function set to zero (eg. RBP is always above Baseline)

## Deal Marketplace

___
### Provider Deal Collateral

*Total Provider Deal Collateral Over Time. [(Source: Filecoin Network Health Dashboard - Market & Deals, Starboard Ventures)](https://dashboard.starboard.ventures/circulating-supply)*

**What It Is**: When engaging on a deal, the provider is obliged to offer a Minimum Deal Collateral associated with it, which adds an additional layer of security to ensure the quality of service. The Actual Deal Collateral is proposed by the client and it can be higher than the Minimum. As of now, the Minimum Collateral has a similiar form to the Consensus Pledge, but with a Target Locked Supply of 2.5%

**Design Goals**
1. Further incentivizing Sector Reliability on Deal-Making Sectors
2. Allowing Clients to decide on higher safety net deal properties.

**Expected Behaviour**
- Deal Collaterals above the Minimum can imply higher marginal risks for the Providers, therefore we would expect higher payments OR lower standards of service compared to Sectors with lower collaterals

**Benchmarks**

- Increased Safety Net Index
- Meaning: Indicates by how many times having a Deal Collateral has increased the capacity of Deal-Making SPs to afford Fault Fees.
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Average of `LockedSupply(t) * DealQAPShare(t) / FaultFee(t)` over time
- Counterfactual Scenario: A historical evolution during which the Deal Collateral is set to zero for all deals.
- Collateral Premium due to Markets Index
- Meaning: Indicates by how much % the Deal Collateral Supply went up historically because of market decisions
- KPI: `Historical Metric / Counterfactual Metric - 1`
- Metric: Sum of `Deal Collateral Supply(t)` over time
- Counterfactual Scenario: A historical evolution during which all deals use only the Minimum for the Deal Collateral

## Gas Dynamics

___
### Base Fee

*Base Fee Over Time. [(Source: Filecoin Network Health Dashboard - Transactions & Usage, Starboard Ventures)](https://dashboard.starboard.ventures/circulating-supply)*

**What It Is**: A dynamical variable that sets how much FIL should be burnt per Unit of Gas at a given time. The Actual Gas Costs for a message is defined as `BaseFee(t) * GasUsed` [(Spec Link)](https://spec.filecoin.io/systems/filecoin_vm/gas_fee/). The dynamics is described on [`chain/store/basefee.go::ComputeNextBaseFee`](https://github.com/filecoin-project/lotus/blob/49c619d65d92ed07282378eab2210dc9482988c9/chain/store/basefee.go) on the `lotus` repository.

**Design Goals**

Computing the total gas cost in FIL for compute operations, and then burning this amount, provides:
- An immediate quantitative measurement of the use of the ecosystem
- An increase in the extant quantity at the current price (for this reason burning the gas fee is often referred to as 'protocol revenue').

Adjusting the base fee in response to utilization is designed to support an _efficient market_, **by interpreting high utilization as "high demand"** for resources and increasing the price accordingly (and vice-versa for low utilization). Consumer **surplus is extracted more efficiently by prioritizing users who value participation the highest**.

In addition, increasing the base fee in times of high utilization may also act as a 'controller' to help reduce utilization, if demand for network use is sufficiently elastic.

**Expected Behaviour**

- Incentivize more efficient network use (e.g. batching vs. single messages)
- Reduce network utilization in times of high congestion
- Increase network utilization in times of low congestion
- Provide a measure of the benefit of using the network, to FIL holders
- Provide a measure of the cost of using the network, to storage providers

**Benchmarks**: Given that the goals are mostly related to market signaling, scoping suitable counterfactual scenarios can require extensive empirical studies / behavioral modeling, which goes beyond the scope of this document.

___
### Target Gas per Block

**What It Is**: A dynamical reference point for adjusting the Base Fee. Actual Gas Usage above it tends to increase the Base Fee and vice-versa. [(Spec Link)](https://spec.filecoin.io/systems/filecoin_vm/gas_fee/)

**Design Goals**

The target gas per block is selected heuristically as 50% of the protocol-specified maximum gas usage of a block. This is to provide 'runway' for a base fee change to affect behavior, with the expectation that:
1. a base fee increase will restrict the demand for network utilization, gradually reducing the amount of gas anticipated per block transaction (and hence the gas used);
2. a base fee decrease will stimulate the demand for network utilization, gradually increasing the amount of gas anticipated per block transaction.

The 'runway' is provided for a gradual adjustment of behavior in response to a base fee change, e.g. in periods of increasing network utilization an increased base fee may not immediately lead to lower use, but the utilization rate will slow and gradually become negative as cost forecasts for network use are updated.

**Expected Behaviour**
- The network continues to function smoothly even as the base fee rises or falls, because the target gas per block is 50% of the protocol-specified maximum.

**Benchmarks**: This mechanism is tighly coupled with the `BaseFee` dynamics, so the same considerations apply.

___
### Maximum / Minimum Base Fee Change

**What It Is**: The increase or decrease in the base fee in response to the comparison of block gas used to the target gas per block is limited to a fixed percentage of the existing base fee. Thus, the base fee change in one epoch is constrained within a minimum and a maximum bound.

**Design Goals**

- Provide network users with greater predictability of the future value of the base fee
- Incentivizing participation in the Filecoin ecosystem by reducing the apparent risk of engaging in block operations

**Expected Behaviour**

- Aggregate storage onboarding does not have a strong correlation with the level of the base fee change from epoch to epoch

**Benchmarks**

- Volatility Attenuation Index
- Meaning: Indicates by how many times the temporal volatility of the Base Fee was attenuated by the Change Boundaries.
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Average of `Weekly Standard Deviation of Base Fee(t)` over Time
- Counterfactual Scenario: Historical Evolution with unbounded base fee changes

## Miscellaneous

___
### Alpha Beta Filter

*Effects of changing the magnitude of the $\alpha$ parameter on a day-level simulation. [(Source: Induced Inertia due to the Alpha Beta Filter Parameters - BlockScience)](https://hackmd.io/@bsci-filecoin/alpha-beta-induced-inertia)*

**What It Is**: Estimates trends of certain system states to extrapolate smoothed future values. These can then be used as estimates of, among others, future network power, block rewards or circulating supply. More context can be found at [Pointers to the Alpha Beta Filter](/IK2npgagSrejaygDkjf2iA).

**Design Goals**
1. Projections needed for future block rewards, especially future 20-day block reward and future QAP.
2. Avoiding adding more attack vectors than benefit gained.
3. Avoiding over/under-smoothing of per-epoch fluctuations.

**Expected Behaviour**
- Accurate projections taking into account per-epoch fluctuations
- Smoothening abrupt movements (in the per-epoch scale)

**Benchmarks**
- Storage Pledge Variation Index
- Meaning: Indicator for how many times the Alpha Beta filter is able to reduce the Storage Pledge per-epoch variation
- KPI: `Abs[Counterfactual Metric / Historical Metric]`
- Metric: Standard Deviation of `Projection of 20d Block Rewards(t) - Cummulative Block Reward(t, t+20d)` over Time (per-epoch)
- Counterfactual Scenario: A historical evolution of the network during which future block rewards were not projected with an Alpha Beta Filter. (eg. the current BR is used instead) All other variables can be assumed to remain the same.
- Storage Pledge Estimation Index
- Meaning: Indicator for how many times the projection for the Storage Pledge becomes closer to realized target.
- KPI: `Abs[Counterfactual Metric / Historical Metric]`
- Metric: Average of `Projection of 20d Block Rewards(t) - Cummulative Block Reward(t, t+20d)` over Time (per-epoch)
- Counterfactual Scenario: A historical evolution of the network during which future block rewards were not projected with an Alpha Beta Filter. (eg. the current BR is used instead) All other variables can be assumed to remain the same.

___
### Transient / Governance Interventions

*[FIPs list](https://fips.filecoin.io/fips/)*

**What It Is**: FIPs can induce economic effects either by transient mechanisms (eg. through exemptions like the Initial Pledge requirements for Testnet miners), parameter tuning (eg. tweak the Baseline Function Growth Parameter), mechanism upgrade (eg. Rebase to QAP) or new mechanisms (Sector Duration Multiplers).

**Design Goals**
- Introduce multi-scale adaptability to the Network, allowing it to change course as new challenges arise, and more innovation and knowledge is accrued.

**Expected Behaviour**

- Increased participation on public forums as Filecoin's relevance grows
- Gradual increase on the heterogenity / categories of the Stakeholders as well as growth in the complexity of requirements for acquiring consensus

**Benchmarks**

- FIP Public Participation Index
- Meaning: Estimator for by how much making FIPs a public process magnified the network participants' attention to Filecoin.
- KPI: `Historical Metric / Counterfactual Metric`
- Metric: Average of `Cumulative Human Hours Spent (fip)` per FIP
- Cumulative Human Hours Spent is most probably an unobservable variable. One valid approach is to estimate it through a variety of methods with varying uncertainties. Keep in mind that spending time doing so will feedback on itself.
- Counterfactual Scenario: FIPs are all decided internally, without public awareness or participation

## References

- Spreadsheets
- [Health dashboard metric mapping](https://docs.google.com/spreadsheets/d/1zSSoDlH2KYxcw-13a3Wk4iObQEPXketDJ-4UwE3rKmg/edit#gid=0)
- [Filecoin Cryptoecon Mechanisms and Attacks](https://docs.google.com/spreadsheets/d/1XUNROPH00Jqq9duFo7TsGmEZ0DB5whBm4g_04uzikCg/edit#gid=1787012696)
- HackMD docs
- [Current cadCAD Critical Cost Derivation](/3VvZTfkgTxe0xjnEx9cvSQ)
- [Digital Twin Business Questions](/M1KRFyu_RbSD22IwR24Ffw)
- [Resource pointers for the BSci + Filecoin collaboration](/J5kThWlMSNaETmivxd0EsA)