Mint Incentivizing Network Transformation (MINT)

[RawthiL (Ramiro | POKTscan)]

@msa6867

No off chain calculations or redistribution of rewards needed. RTTM would simply consist of a subsidy component (either fixed as in ARR and RDI, or diminishing as in SER) plus a percentage of GatewayFeePerRelay. E.g.,

As you say this can be seen as simple change of cost plus a bias:
MaturityRelayCost = PercentBurntoMInt * MaturityRelayCharge * epsilon
and then just
RTTM = RTTM_0 + RTTM_proposed
The one is a fixed bias in POKT and the second is the proposed controlled RTTM obtained from the linear functions ans so on. This is more complex than the current approach that some already call too complex.
As you say below, maybe a hard cap on RTTM will solve this more simply.

---

@msa6867

The maximum value I foresee for MaturityRelayCharge is around 0.0000035. Even that may be a bit too high. I can go into specifics if needed but will not unless needed.

I would love to hear your rationale on this, as we need consensus on these values. Nevertheless I have to admit that the feedback from portal runners such as @poktblade and @ArtSabintsev are the ones we need to give more weight.

@msa6867

For GatewaysBootstrapUnwindStart, I think a minimum of 2B relays/day and perhaps even 2.5 or 3B is desirable to maximize prioritized focus on growth. I believe it will help for existing and new operators to have the simplicity of fixed, predictable pricing during this period. That being said, I do see value in developing a game plan now for weaning off of subsidies, and your approach is as good as any I have seen with respect to demand-side fees

I agree that giving some flat rate for a little while is OK and might help them. More after seing that growth is not going as fast as expected.

@msa6867

The proposed mechanism for setting RTTM is not sound. Please see my comments to the RDI proposal as almost everything I said their applies here. tl;dr, denominating the supply side in USD in addition to the demand side causes a complete decoupling of USD to POKT conversion rate from POKT fundamentals eliminating needed price discovery / price feedback loop that will help price find a floor, leading to risk of hyperinflation during the pre-maturity regime (relays << GatewaysBootstrapEnd).

I agree with the objection of denominating the supply side in USD, but given the token exchange rate instability and the low weight that the Pocket Network has in the relay market, it is necessary to give up some control over the emissions to try to keep the exchange rate in rails (this is a consequence of the economic trilema, something that we cannot avoid). We would be glad to give up this as soon as we can and transition to a POKT denominated economy.
Please keep in mind that in contrast to RDI, this proposal is only viable is parameters are set together, “hyperinflation” is only possible if there is no burning counterpart.

@msa6867

See, eg, the following example where I have populated the parameter set with as realistic values as possible and explored what if price continues to drop to sub-cent level.

Just to clarify to everyone, a price of 0.001 USD/POKT is a lot. Is the same as the one that POKT suffered going from 1 USD/POKT to 0.03 USD/POKT. While I highly doubt that we can suffer such depreciation process again, everything is possible. It is correct to analyze these extreme cases.

@msa6867

Granted this is better than RDI, because here at least the possibility for hyper inflation only occurs in the pre-maturity regime. Post maturity (eg >10B relays per day), a proper choice of parameters will guarantee the net mint is deflationary, but the problem remains that the feedback mechanism that can help token price rebound from ATL is removed and the system is stuck with high values for both RTTM and GFPR which will keep price depressed. See e.g., the same parameter set as above when maturity is reached at 10B relays.

This is an interesting take, if I understand correctly you are saying that our economy might be stable in maturity but the nominality is too high. In simple words, the exchange rate would be stable low in 0.001 USD/POKT. We don’t want this.
While I believe that this is a very unlikely outcome I agree that we need safeguards.

@msa6867

Since we are at RTTM ~= 500 right now (and dropping), and we are not in an environment where anyone is seeking to raise RTTM, I think it to be a reasonable expectation for proposed changes to the mechanism for setting RTTM to show how their methodology is at least bounded to RTTM <=500. This can be as simple as adding an explicit bound of MIN (500, x). That would satisfy the concerns raised above about risk of hyper inflation, removal of price feedback mechanism, etc.

I like this idea, let me explore it. I will test the cases of extreme POKT depreciation:

• 0.0155 USD/POKT (1/2 current price, as reference for main post graphics)
• 0.003875 USD/POKT (1/8 current price)
• 0.0019375 USD/POKT (1/16 current price)
• 0.00096875 USD/POKT (1/32 current price, almost the ~0.001 that is used in the shown calculations)

Keeping the proposed values and setting a hard threshold of RTTM <=500

This simple addition set a cap to inflation of ~20%. Anyway, I feel it is very difficult to reach this situation, as we cannot possibly support all the supply side with 15 K USD / Month, probably the exchange rate is going to stabilize before or the supply side will collapse.

Using the new values and setting a hard threshold of RTTM <=500

The new values mentioned by @msa6867 are:
MaturityRelayCharge = 0.0000035
GatewaysBootstrapUnwindStart = 3 B
MaturityRelayCost = 0.75 * 0.0000035 = 0.000002625

Results are similar wrt supply growth. The main change observed is in the gains of node runners and servicers payments.

Differences in parameters sets

To compare with proposed values to the ones in the analysis, I will use the parameters mentioned here but the exchange rates in the original analysis.

The adjustment of the prices to the supply side and the charges to the gateways moves the supply attrition threshold to ~8 B relays / day. This is paid by a cut of ~50% to node runners incomes. Also the movement of the GatewaysBootstrapUnwindStart does not create a significant change to the supply growth profiles, as the GatewaysBootstrapEnd is unchanged. The extended “stability” of the gateway price is paid with a more step growth of the GatewayFeePerRelay during the gateway bootstrap unwind phase.

Conclusion

While I still wait for Gateways runners opinions on the subject, I have no functional objection on the proposed changes (new values + cap).
I could argue that the proposed cuts to node runners are too high, because we will not reach current levels of emissions (denominated in USD) until ~6B relays/day as opposed to the proposed parameter that achieved this in 4 B relays/day, however this is about projection.