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.,
RTTM = RTTM_0 + PercentBurntoMInt * GatewayFeePerRelay * epsilon,
where RTTM_0 is that of SER or ARR or RDI or whatever subsidy-based mechanism is decided upon.
[Note that in v1 the above would be replaced with
RTTM = RTTM_0 + PercentBurntoMInt * AppBurnPerRelay * epsilon ]
I think you will find that when all is said and done, your proposal for setting RTTM can basically be deconstructed into something like this equation.
================
Following is feedback on the specifics of the proposal:
On the demand side:
- The proposed mechanism for setting GatewayFeePerRelay seems sound
- 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.
- 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
- Proposed values of MinBootstrapGatewayFeePerRelay and GatewaysBootstrapEnd seem fine
On the supply side:
- 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).
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.
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.
Going back to my proposed alternative construct:
RTTM = RTTM_0 + PercentBurntoMInt * GatewayFeePerRelay * epsilon,
where the first term is a subsidy/bootstrap component and the second term is a percentage of the burn, it is possible for the second term to be denominated in USD. But it is not possible for the subsidy component (RTTM_0) to be denominated in USD without threatening to harm the project.
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.
- Notwithstanding the above, if MaturityRelayCharge is set to 0.0000035 or smaller (as suggested above), this implies MaturityRelayCost even smaller. I use 0.000003 as a starting point (~85% of MaturityRelayCharge). This is probably still relatively too high (perhaps 75% of MaturityRelayCharge is a better target? ).
- I kept MaxBootstrapServicerCostPerRelay close to your original (0.000009) for the sake of providing starting continuity between your proposal and the ARR proposal:
- Proposed values of ServicersBootstrapUnwindStart and ServicersBootstrapEnd seem fine