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

Conversation

jnthnvctr
Copy link
Contributor

Abstract:
The mining reserve 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".

This proposal seeks to remove the mining reserve. 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.

Discussion:
Link

FIPS/fip-set-the-mining-reserve-to-zero.md Outdated Show resolved Hide resolved

## Simple Summary

This proposal aims to remove the mining reserve tokens [282.9m](https://filfox.info/en/address/f090) by setting its value to 0. This does not preclude other FIPs from being proposed to create new tokens (as future incentives, funding iniatives etc).
Copy link
Member

Choose a reason for hiding this comment

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

What does remove mean? burning?

Edit: in the later session "removing from total supply" - lets add it here so it clearer since the begining.. "remove...... and the Filecoin Toal supply will be updated from X to Y"


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".

This proposal seeks to remove the mining reserve. 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.
Copy link
Member

Choose a reason for hiding this comment

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

is the proposal to burning tokens, or are you proposing to change

  • the fixed max filecoin token supply to be (2B - mining reserve)
  • move Filecoin away from a fixed token supply economy to an unfixed one (unlimited minting)?

Copy link
Contributor Author

@jnthnvctr jnthnvctr Aug 1, 2024

Choose a reason for hiding this comment

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

This proposal only touches the mining reserve - I think the other discussion (on uncapping baseline minting) had less momentum behind it.

I still think thats a discussion (honestly rethinking how inflation works) that should be on the table - but not a part of this proposal

Tbc the part that does touch filecoin as not being a fixed supply currency would be normalizing the idea that FIPs might include proposals to mint new tokens (but also then require sufficient buy in from the community to accept those proposals)

Copy link
Member

Choose a reason for hiding this comment

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

This proposal only touches the mining reserve - I think the other discussion (on uncapping baseline minting) had less momentum behind it.

I still think thats a discussion (honestly rethinking how inflation works) that should be on the table - but not a part of this proposal

I don’t see how my comment lead to any of these points. The editing suggestion I’m trying to give you here is similar to #1039 (comment) - please be more specific on what you mean by “removing”

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 reinforces an anchor around Filecoin being a fixed supply currency. Given there is always the ability for the community to fork to change the supply, this is an unnecessary meme to reinforce - but constricts discussion.
3. 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.
4. Filecoin's inflation is already quite high relative to other ecosystems - removing the mining reserve should change the default from creating net new sources of inflation to bring new value flows into the ecosystem (vs optimizing the inflation already in the network)
Copy link
Member

Choose a reason for hiding this comment

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

Peer review: If the goal is to fix inflation, burning tokens is not the right strategy. Working on getting paid demand for filecoin usage and services and increasing FIL utilization will be a more sustainable strategy. (and remove the mining reserve may prevent new mining/service opportunities to exist)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think you're misunderstanding - I'm not saying we can't have new sources of inflation. I wrote at the top we could - the difference here is that we're not relying on an argument that 300m tokens were already printed therefore its the amount we should be willing to spend (which given FIL's fiat value changes substantially has been worth anywhere between $900m and 69b).

The default should not be to keep our existing high inflation and just add more tokens in the mix - but that doesnt preclude it if thats what the community really wants.

I don't think setting the mining reserve actually changes the activation energy on creating new sources of dilution - we'd still be having a discussion about how much dilution tokenholders are willing to accept.

Copy link
Member

Choose a reason for hiding this comment

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

Same as above, I don't think there's much of an explicit or implicit connection between the two things. #1 and #3 create sufficient motivation without having to stretch one's imagination.

4. Filecoin's inflation is already quite high relative to other ecosystems - removing the mining reserve should change the default from creating net new sources of inflation to bring new value flows into the ecosystem (vs optimizing the inflation already in the network)


## Spec
Copy link
Member

Choose a reason for hiding this comment

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

I think you should include a design rationale session to compare the the pros and cons between burning tokens vs set values 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.

Agreed but that should be part of the rationale section, where it already is -- possibly not at the time of the comment. In any case, that will need further work, and this section will need revamping too.

@jennijuju
Copy link
Member

The first editor pass is ✅ - need clarification on what "remove" means in multiple places and is missing product, security and incentive considerations (see the template here); The rest is clear to me.


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.
Copy link
Member

Choose a reason for hiding this comment

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

"There has been some discussion" etc isn't necessary, just lay out the alternatives and considerations.

Please describe what burning means: crediting the tokens to f099 so that the total (accounting) supply remains 2bn.

Some more considerations expounded in this thread.

Comment on lines 68 to 69
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

Choose a reason for hiding this comment

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

This section is meant to refer to the actual code, rather than re-state the spec. Delete this for now, we can link a PR later.

@anorth
Copy link
Member

anorth commented Aug 5, 2024

Please take FIP number 0093. Update the filenames and text to match that.

@anorth anorth changed the title Set the Mining Reserve to Zero FIP-0093: Set the Mining Reserve to Zero Aug 5, 2024

## Simple Summary

This proposal aims to remove the mining reserve tokens [282.9m](https://filfox.info/en/address/f090) by setting its balance to 0. 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)).
Copy link
Member

Choose a reason for hiding this comment

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

It appears that the discussion is quickly converging on burning the balance and maintaining the total supply, so this will likely be updated. I'd anyway avoid referring to a specific value for the total supply given that's ever changing.


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 reinforces an anchor around Filecoin being a fixed supply currency. Given there is always the ability for the community to fork to change the supply, this is an unnecessary meme to reinforce - but constricts discussion. 300m should not be assumed to be the default (in either direction as a maximum or minimum) for the amount of tokens available for new mining - any new proposal should include its own assessment for the tokens required.
Copy link
Member

Choose a reason for hiding this comment

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

I really don't think this has any impact. Filecoin is a fixed supply currency. Sure, that can always be changed, but I don't think the existence of a mining reserve has any impact on that perception or determination.

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 reinforces an anchor around Filecoin being a fixed supply currency. Given there is always the ability for the community to fork to change the supply, this is an unnecessary meme to reinforce - but constricts discussion.
3. 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.
4. Filecoin's inflation is already quite high relative to other ecosystems - removing the mining reserve should change the default from creating net new sources of inflation to bring new value flows into the ecosystem (vs optimizing the inflation already in the network)
Copy link
Member

Choose a reason for hiding this comment

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

Same as above, I don't think there's much of an explicit or implicit connection between the two things. #1 and #3 create sufficient motivation without having to stretch one's imagination.

4. Filecoin's inflation is already quite high relative to other ecosystems - removing the mining reserve should change the default from creating net new sources of inflation to bring new value flows into the ecosystem (vs optimizing the inflation already in the network)


## Spec
Copy link
Member

Choose a reason for hiding this comment

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

Agreed but that should be part of the rationale section, where it already is -- possibly not at the time of the comment. In any case, that will need further work, and this section will need revamping too.


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. 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 decereasing). However, it should be noted that the difference between these two in practical terms seems very slight and is mostly subjective.
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
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 decereasing). However, it should be noted that the difference between these two in practical terms seems very slight and is mostly subjective.
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

This should not affect the product as these are not tokens that are being used. Any future proposal that might need new sources of inflation is not blocked from including new incentives in their proposals.
Copy link
Member

Choose a reason for hiding this comment

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

Although this is subjective, I think there is a product consideration, in that these tokens were set aside to support future network functionality and that will cease to be the case. We can agree that the impact is minimal, for the reasons explained further above, but we should'd just disregard it.


## 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.
Copy link
Member

Choose a reason for hiding this comment

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

Likewise, I think this discounts a core argument for this proposal, which is that there is currently a _dis_incentive to hold FIL due to the perceived room for devaluation. Reducing that disincentive sounds like an incentive consideration.

@The-Wayvy
Copy link

Can we put this in last call?

@jennijuju
Copy link
Member

Can we put this in last call?

The authors have to address editors reviews for this fip to land as a valid DRAFT first.

@anorth
Copy link
Member

anorth commented Sep 23, 2024

@jnthnvctr are you still on this or have you abandoned it (and why?). You have a bunch of editor feedback to address, but nothing that would prevent a perfectly good FIP coming out of this that can then be properly put to the community for discussion and governance process.

My impression is that there are many people in support of this idea, but they're currently pseudo-blocked from doing anything constructive with it because you "own" it having drafted this FIP. Would you please follow through? Alternatively, if you abandon it and make it clear that it's merely because you have lost interest, the space will open up for someone else to take over.

@jnthnvctr
Copy link
Contributor Author

bleh - didnt mean to close this out, was trying to incorporate the changes onto the fork (makign the edits here - will try and figure out how to undo and link back here so we can keep the thread)

@anorth anorth reopened this Sep 23, 2024
@anorth anorth requested a review from rvagg as a code owner September 23, 2024 21:44
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

Comment on lines +11 to +16



# FIP-0093: Set the Mining Reserve to Zero


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

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

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.

## 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)).

@rvagg
Copy link
Member

rvagg commented Sep 26, 2024

With some precision in details around new total supply and minor whitespace cleanups this lgtm ✅ 🚢

@Fatman13
Copy link
Contributor

Fatman13 commented Nov 22, 2024

Is there anything blocking this from being merged? Seems that two editors have approved? @jnthnvctr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants