Hi Vini,
Thank you for your thoughtful note as always and for your support. I’m hopeful the responses below address your points and are useful as we continue the discussion on both parts.
Fixed supply as an experiment: I agree with you that there is no battle-tested example of a network that has made this transition successfully, and that is precisely why Part 2 was presented as a direction and not a proposal. We are not proposing mechanics today, and we will not bring a proposal forward until there is a design that addresses security, decentralization, and ecosystem funding with the same rigor as the issuance change in Part 1. Any proposal that comes out of this work will go through its own discussion and vote.
Precedent from other networks: The examples you raised are helpful. My read is that the common problem across them was not the fixed supply itself but the absence of a sustainable source of funding for security and development once issuance was no longer providing it. A fixed supply only works after that problem has been solved, which is why the principle in the post is that the network pays for what it needs out of what it earns. Your point on Bitcoin is well taken. The supply schedule is fixed, but whether fees can replace the block subsidy remains an open question, so we don’t view Bitcoin as proof of the model either.
Part 1 as a source of data: I think this is the most important point in your note. A gradual reduction every epoch over 24 months will give the community a clear record of how staking participation, validator count, and delegation respond as issuance declines. The last reduction gave us one data point. When NEAR moved from 5% to 2.5%, dollar revenue per staked NEAR fell about 75%, and the validator set still grew from 342 to 413 active today. A second, slower reduction will provide better data, and we would much rather design Part 2 from that record than from theory.
Research: We would welcome your participation in the research. If you do look further at the networks you mentioned, the most useful output would be the specific failure in each case (security spend, validator concentration, or development funding), since that will tell us which constraint a design for NEAR needs to satisfy first.
I hope the thoughts above are helpful, and I’m happy to address any further questions or comments you may have.