Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIP-0093: Set the Mining Reserve to Zero #1039

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 73 additions & 0 deletions FIPS/fip-0093.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
---
fip: "0093"
title: Set the Mining Reserve to Zero
author: jnthnvctr (@jnthnvctr)
discussions-to: https://github.com/filecoin-project/FIPs/discussions/1030
status: Draft
type: Technical
category: Core
created: 2024-07-25
---



# FIP-0093: Set the Mining Reserve to Zero


Comment on lines +11 to +16
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# FIP-0093: Set the Mining Reserve to Zero
# FIP-0093: Set the Mining Reserve to Zero

## Simple Summary

This proposal aims to remove the mining reserve tokens. This does not preclude other FIPs from being proposed to create new tokens (as future incentives, funding iniatives etc). After this FIP, the total supply of FIL should be ~1717066618.96 (2b minus the current amt in [f090](https://filfox.info/en/address/f090)) - though future FIPs may change this number.


Comment on lines +20 to +21
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

## Abstract

The [mining reserve](https://spec.filecoin.io/systems/filecoin_token/token_allocation/) was intended to be a reserve of tokens to incentivize future types of mining. In the spec, this is noted to potentially "[not] be enough" and that the community will "decide... whether to make adjustments with unmined tokens" (last line of the paragraph on the [mining reserve](https://spec.filecoin.io/systems/filecoin_token/token_allocation/)).

This proposal seeks to remove the mining reserve by setting `f090` to have a balance of 0. This does not preclude new tokens from being created - rather that any new incentives should be created at the point when new forms of mining are introduced rather than relying on a set of pre-minted tokens.

## Change Motivation

There are a number of reasons why the mining reserve can be viewed as a net cost:
1. The role of the mining reserve is non-standard - at the time of authoring, no other L1 has this amount of supply left up to potential release (~50% of the current supply, 15% of the total max supply) which creates a large gap between the FDV and Market Cap.
2. The mining reserve requires a FIP to use (the same process for creating new tokens) - in the event these tokens are needed; its unclear there would be any _less_ pushback in the community if were to create new sources of dilution.



Comment on lines +33 to +35
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

## Spec

1. Set balance of `f090` to 0.
2. Adjust all circulating supply dependencies and the invariant checks to recognize the total supply is no longer 2b given the mining reserve has been set to 0.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a TotalFilecoin that's used for a few things:

  1. Invariant check as mentioned here, after summing up all the accounts it checks that it's equal to this number: https://github.com/filecoin-project/go-state-types/blob/aff1b8dbe7fd175eb2d9e7ca7e5da00e125a5650/builtin/v15/check.go#L203-L206
  2. 3 exported methods: DealClientCollateralBounds, DealPricePerEpochBounds and DealProviderCollateralBounds - each of which return a min and a max, where the max is this TotalFilecoin. In Lotus at least, we no longer use the first two, but the last is exposed as StateDealProviderCollateralBounds, which is being codified in the Common Node API @ Common Node API #1027

Should we find out precisely what this new number should be and replace it with that? Or do something else with these APIs?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new total supply would be exactly 1717066618961773405230063046 attoFIL. That's current TotalFilecoin minus f090's balance.

So we could do this?

Suggested change
2. Adjust all circulating supply dependencies and the invariant checks to recognize the total supply is no longer 2b given the mining reserve has been set to 0.
2. Adjust all circulating supply dependencies and the invariant checks to recognize the total supply is no longer 2b given the mining reserve has been set to 0. The new total supply value used for invariant checks and other uses of "maximum Filecoin", should be set to `1717066618961773405230063046` attoFIL.

Copy link
Member

@anorth anorth Sep 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe total supply is defined to include the burned balance. It's the 2bn sum of all address balances.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The invariant check does a total of all address balances to get to 2b. If we're not burning, but setting to 0 as per this FIP then we're expecting a new total of 1717066618961773405230063046.


## Rationale

The proposal aims to move away from relying a fixed amount of tokens in the mining reserve that might be used for new mining, to having new FIPs be proposed explicitly creating (or redistributing existing) incentives.

There has been some discussion about whether this should be achieved by setting f090 to 0 or by burning the tokens in f090.

One pro to burning is that there is a "narrative" value to saying the network is burning 15% of its max supply. However, this has a related con - in that it may overly anchor the ecosystem to only destroying tokens without considering how inflation can be used to productively grow the ecosystem. Specifically, others in the community have proposed repurposing the Mining Reserve to incentvize other parts of the "value chain" - eg incentives to bring paid revenue on chain, acquire / incorporate protocols, fund future research and development. If the tokens are simply burned (and the community anchors to 2b as the max supply), these initiatives may be harder to fund in the future.

One pro to setting f090 to 0 is that it functionally has the same effect as burning - without the same connotations of simply destroying tokens for the sake of it. If the goal is to not anchor heavily to 2b, this nudges slightly closer to treating the supply as a dynamic number. One slight con, is that it may not have the same "shock" value as saying burn.

For the intended purposes, listed above in Change Motivation, setting the mining reserve to 0 achieves the main goals (and in the author's opinion doesn't substantially sacrifice a narrative goal as the total supply of the network is still decreasing). However, it should be noted that the difference between these two in practical terms seems very slight and is mostly subjective.

## Product Considerations

Depending on perspective this may affect the product. These tokens were intended to be used to incentivize future types of mining. However, any future proposal that might need new sources of inflation is not blocked from including new incentives in their proposals - and this could include using incentives for other forms of more productive activity (that are not specifically mining - e.g. a product development funds)

## Security Considerations

This should not affect the security as these tokens are not used to incentivize any action. Any future proposal that might need new sources of inflation to help incentivize / secure new mechanisms are not blocked from including new incentives in their proposals.

## Incentive Considerations

The proposed change requires future explicit proposals (aiming to incentivize new forms of mining) to explicitly mint new tokens. This should not change the difficulty of making such proposals, as both (using the mining reserve, creating new tokens) would have the short term effect of diluting stakeholders. This changes the optics of having large amounts of potential dilution that do not have a definite time horizon to entering the supply (which can have a negative signal).

## Implementations

1. Set the balance of `f090` to 0.
2. Adjust all circulating supply dependencies and the invariant checks to recognize the total supply is no longer 2b given the mining reserve has been set to 0. The total supply of the token should be the total supply of FIL should be ~1717066618.96 (2b minus the current amt in [f090](https://filfox.info/en/address/f090)).
Copy link
Member

@rvagg rvagg Sep 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
2. Adjust all circulating supply dependencies and the invariant checks to recognize the total supply is no longer 2b given the mining reserve has been set to 0. The total supply of the token should be the total supply of FIL should be ~1717066618.96 (2b minus the current amt in [f090](https://filfox.info/en/address/f090)).
2. Adjust all circulating supply dependencies and the invariant checks to recognize the total supply is no longer 2b given the mining reserve has been set to 0. The total supply of the token should be the total supply of FIL should be `1717066618961773405230063046` attoFIL (2b minus the current amount in [f090](https://filfox.info/en/address/f090)).



Comment on lines +69 to +70
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

## Copyright Waiver

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -129,5 +129,6 @@ This improvement protocol helps achieve that objective for all members of the Fi
| [0090](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0090.md) | Non-Interactive PoRep | FIP | luca (@lucaniz), kuba (@Kubuxu), nicola (@nicola), nemo (@cryptonemo), volker (@vmx), irene (@irenegia) | Superseded by [FIP0092](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0092.md) |
| [0091](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0091.md) | Add support for Homestead and EIP-155 Ethereum Transactions ("legacy" Ethereum Transactions) | FIP | Aarsh (@aarshkshah1992)| Accepted |
| [0092](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0092.md) | Non-Interactive PoRep | FIP | luca (@lucaniz), kuba (@Kubuxu), nicola (@nicola), nemo (@cryptonemo), volker (@vmx), irene (@irenegia), Alex North (@anorth), orjan (@Phi-rjan) | Final |
| [0093](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0093.md) | Set the Mining Reserve to Zero | FIP | jnthnvctr (@jnthvnctr) | Draft |
| [0094](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0094.md) | Add Support for EIP-5656 (MCOPY Opcode) in the FEVM | FIP | Michael Seiler (@snissn), Raúl Kripalani (@raulk), Steven Allen (@stebalien) | Last Call |
| [0095](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0095.md) | Add FEVM precompile to fetch beacon digest from chain history | FIP | @ZenGround0, Alex North (@anorth) | Last Call |
Loading