The value of the model is that is very easy to change from v0 oriented to v1 oriented model. The main mechanisms of Pocket wont change much in V1, some actors can change and new ones appear, and some minting mechanics are modified, but the variables and metrics that we need to track will remain.
Right now V1 will be launched with a single permissioned fishermen and no tokenized portals, besides a change in how relays are distributed (outside the proposed model initial scope) and removal of stake weighting, the minting logic will be very similar.
Both of them are possible, the first one only require the simulation to be run for each set, the second requires the coding of a mechanism that updates them. This is like the implementation of price variation or staking incentives in the Ethereum model.
Yes it should be a parameter, I will modify that. I do not intend to model $POKT price at any extent. I leave that out and to be set as a fixed value or to controlled by any kind of external process.
I propose total staked and avg. bin size since I do not expect to track nodes stakes so closely (initially). I mean, we could separate the total stake into multiple bins and calculate then the minting based on how much is staked on each bin, but it should be redundant. Stake weighting will not affecting income at this level of abstraction and the metrics for node-running revenue should not be different (POKT earned by POKT invested should be the same for each bin).
The existence of “Avg. Bin Size” is only for calculation of the total minted. In a V1 scenario it can just be ignored (not used). Also, I think that the whole concept of stake weighting (among other things) should be gone in V1 if we want to maximize the diversity of the network, but this is other subject that I will later address in the V1 github.
Total Jailed makes no sense at this level of abstraction (neither for validators), i will remove this for clarity.
This is an edge case I think, they are welcome in the ecosystem but I think that they are not the main actor. Also, the model as initially conceived, has no granularity on different chains. This “dApp” servicers would be interested only in projections for the specific chain that they use, as they will only stake for that one.
Avg. Slashing this was duppled, as you say, it should be a parameter not a variable. I will remove it and separate it into those categories.
I expect the model to be run for months normally. Maybe the parameter should be Target Daily Emission, and then set RTTM as a variable. The target daily emission is a value controlled by an external mechanism. Also, it is a value that is interesting to modify over time, just to answer “what if” questions or build models past the SER running time.
I also expect this to happen, but I would not go that deep in an initial model. There many complex stuff that should be discussed specifically for that. Probably fist in the form of a V1 github issue.
New actors can be added later, I dont think that we need this right now if we want to go up to app burn. Also fishermen will start as DAO owned actors, they will have no effect on network-wide minting initially.
For v0 I just used “ABR” but that is not clear enough, it seems like a flag.
Maybe we can use USDRelayTarget and some logic?
No need to be hardcoded, I imagine two ways of doing this, model everything down to a session and if a larger step is chosen (like a day or week), simply run many sessions per model update (will depend on computational burden). An other could be having two models, a max granularity model for sessions and a simplified one for larger periods (days or weeks). At most we will need to have two different models and only for minting process which require single node earning tracking, all simplified models are just larger draws of the same fixed distributions.