Mint Incentivizing Network Transformation (MINT)

[RawthiL (Ramiro | POKTscan)]

@msa6867

1. The proposal will be cleaner and easier to follow if you do not introduce new DAO-governed parameters. …

I modified the parameter sections to make this distinction more visible. As you say the only parameter being modified is the RTTM, the others are “DAO instructions” or guidelines. Anyway there must be consensus over them and their values must be agreed upon.

@msa6867

2. This is a v0-era proposal (RTTM is not a v1 parameter and GFPR is set to be removed with v1). …
   …
3. I think there is universal agreement that GFPR = $0.00000085 is a highly-subsidized rate , not a “maturity” rate. …
4. Likewise, there is (I assume) near-universal agreement that in maturity emissions will grow, likely linearly, …

We address this in the new rationale section “On the timing and implementation of this proposal in V0 and its projection to V1” (see previous post or the edited main post).

@msa6867

3. If at all possible, I suggest separating this into two proposals, one for setting GFPR and one for setting RTTM. If not possible, I suggest adding to …

Separating the proposal is not possible. We think that thinking of these parameters as different and unrelated stuff is the paradigm that we must abandon in favor of a more systemic view of the network. We added some rationale about this in the main post (section “On the timing and implementation of this proposal in V0 and its projection to V1”). Also, the explanation provided by @shane on this matter reflect what we believe too.

Regarding on how the proposal would look like if we keep SER and only change the GFPR, there is a mention to this in the original post text:

@RawthiL

Please note that the lines denominated “SER” are calculated using a constant GFPR of USD 0.00000085 which is the current scenario. In case that the SER proposal is applied to the proposed increase of burning, the “equilibrium” is reached at 6 B relays/day and 5 B relays/day for the current and end-of-SER minting values.

Also, in the notebook provided in the “Resources” section, we added a simple flag to turn on/off this hypothetical scenario. Feel free to explore the possibilities. It can be found on the “Run Options” block:

# If true, the calculations use the constant burning price of 0.00000085 USD/relay
# wich is the current state of the network.
# If false, the values for the "SER" curve are calculated using the proposed
# increase of GFPR. This means that it would be a "hybrid" scenario, not the
# current one nor the proposed.
USE_CONSTANT_BURN_FOR_SER = True

``

@msa6867

I certainly empathize with the desire to reintroduce the growth of emissions as relays grow and we have discussed privately the deficiency of WAGMI/FREN/SER in regard to this decoupling. Have you considered the much simpler proposal of simply tacking on an extra component to emissions equal to a percentage (less than 1) of GFPR-based treasury burn; e.g., that could be a stand-alone proposal to modify SER or you could work with PNF to amend ARR proposal to include a percentage-of-burn component to emissions. This really is in keeping with the march toward maturity idea of burn&mint with an ever-decreasing subsidy,

This mechanism (as first glance) seems more complicated as it requires the calculation and redistribution of rewards to be done off-chain. Nevertheless I look forward to discuss it on its own if you decide to create a proposal using this concept.

@msa6867

… Node providers are more like the widget makers of the factory rather than the sales people of the factory. Of course we want the “widget-makers” to be evangelists for the widgets they make, and the factory offers referral incentives etc, but ultimately the factory relies on it’s sales force to bring in sales.
…

Well I certainly would not like to make widgets in your factory. Your system might work when the labor force has nowhere to go, it does not work for educated/skilled workforce and it certainly wont work for a permissionless node runner environment that can now sale their service to anyone. No new contributor will enter the system if you say them “you are earning peanuts and will earn peanuts if we produce more. But don’t worry we will think of something later.”

@msa6867

… Of course, your point is that it is reasonable for the widget maker to expect to get paid based on the number of widgets it makes… totally true once the system reaches operational maturity, but in a period of time where the compensation is still mostly subsidy, I think it is equally reasonable for the widget makers to grow into fixed subsidies that are set in a way to optimize efficiency over quantity

The values proposed (which can be changed tho) were set to create a harsh environment for node runners. This proposal (as it is now) wont produce much more rewards than ARR, so the idea of “optimize efficiency over quantity” is backed into the parameter set. The difference is that we shed some light on where the subsidy goes and for how long (measured in production per day).

Delaying the alignment of node runner incomes to relays produced by day will only grow the discomfort of node runners (which are ecosystem builders). Telling the supply side of the network: “Don’t worry we will think of something later” but not define when and how that will happen (when we can), is completely arbitrary. There is no guaranty of a brighter future for them.

@msa6867

In a single-gateway environment, it is reasonable to reduce wholesale-price subsidies as a function of total system relays, as it is reasonable to expect the gateway provider to become less reliant on subsidies as it grows into its economies of scale. In a multi-party environment, the economies of scale each gateway provider is able to achieve is based solely on traffic handled by that provider, not on the traffic handled by the entire system. Therefore, there is no basis for setting subsidy levels on the total system traffic.

Since GFPR is an off-chain parameter meant to get us through the remainder of v0, perhaps it is possible to re-invent it as being able to take on different values based on gateway-provider-specific metrics. I.e., base the fee level not on total system relays, but on the relays served by each specific provider? That way greater subsidies can be given to start-up gateways to incentivize their start up period, with subsidies being reduced as they mature and achieve economies of scale.

The same argument can be given for node runners. It is expected that a node runner become less reliant on subsidies as it process more relays. Check the Game of Providers post, you will see that smaller node runners are suffering more, should we incentivize them? I think the community just tells them “do what you can, see you on the other side”.
We need to think as a protocol, gateways are just as permisionles as node runners, and they should not be treated differently at a protocol level. We can think of DAO grant and incentives. On that regard, I really like this idea:

@Cryptocorn

I think it’s also beneficial that by subsidising the Gateways from the DAO directly, the amount of POKT burned increases as the GFPR increases - so will help our placing on metric boards, instead of subsidizing at the GFPR level and lowering the amount burned.

Ultimately its going one way than the other to reach the same destination, but the optics and marketing are far better if we significantly increase the burn.

@Cryptocorn

While that debate belongs in the Era discussion, it move to the above with the question of ‘how and how much are we going to subsidise relays for Gateways?’ We could either keep the 0.00000085 price static for a longer period of time, or raise it earlier but then send direct subsidies to the Gateways to help offset these costs amongst others. Either way, the DAO is in effect subsidising the Gateways.