# radCAD Base Model Discussion **URL:** https://forum.pokt.network/t/radcad-base-model-discussion/3969 **Category:** Research **Created:** [February 14, 2023, 6:59pm UTC](https://forum.pokt.network/t/radcad-base-model-discussion/3969 "2023-02-14T18:59:47Z") **Posts on this page:** 1 **Showing post:** 4
### Author: ![RawthiL](https://forum.pokt.network/user_avatar/forum.pokt.network/rawthil/32/2971_2.png) [@RawthiL](https://forum.pokt.network/u/RawthiL) #### Post date: [February 20, 2023, 3:16pm UTC](https://forum.pokt.network/t/radcad-base-model-discussion/3969/4 "2023-02-20T15:16:54Z")
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. > [@msa6867](#): > > What is your idea for handling such “quasi-variables” (values that vary over time, but not as a result of the cycling of the simulation) I see two possible approaches: one, these are parameters set to a fixed value, as you indicate, and the simulation is run sufficient number of independent times with different parameter set to build up probability statistics. Or two, these parameters are fed into a single simulation exercise via a file containing a set of values which updates to next value in the series at specified time boundaries (e.g., once per day for number of relays per session.) 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. > [@msa6867](#): > > **Price** : I am trying to understand what kind of process could cause price to vary as the simulation cycles. The difference between price as a variable vs parameter is, I believe, the difference between building a micro-economic model and building a macro-economic model (because there are so many factors affecting POKT price besides what happens within the POKT ecosystem). In order to keep the complexity of the model from mushrooming out of control, I think price ends up being one of those stochastic parameters described above. 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. > [@msa6867](#): > > **Servicer Variables** : Perhaps this could be tweaked to be Total (and Total staked) Per Bin, Avg Jailed Percentage (is this even needed??), delete “Avg Bin Size”. Note that bins are needed only if we build a v0 model (see above discussion). The whole concept of bin goes away in V1. In its place we will need some kind of Servicer POKT Staked distribution to be defined (as I don’t foresee specifying a single mean value to be sufficient for modeling purposes). 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. > [@msa6867](#): > > **Servicers Parameters** : Note that a fourth servicer type is needed which might be called “dApp” to capture the servicer type that Vitaly advocates where a dApp is running a chain validator anyway and runs a POKT servicer for that one chain to earn some supplemental income at near zero additional cost. 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. > [@msa6867](#): > > **Validators Parameters** : **Avg. Slashing** : probably keep this here and delete from Parameters. Make it per validator type (cloud/BM/DIY). **Slashing Prob** : probably delete this here and keep as Parameters. Make it per validator type (cloud/BM/DIY). **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. > [@msa6867](#): > > **RTTM** : Whether this is a parameter or a variable depends on the duration of simulation needed to answer whatever is the objective of running the simulation. If less than one week, it can be a parameter; if greater than one week but less than one month (assuming SER passes) it will be a valriable, and Target Daily Emission is a fixed parameter. If longer than one month, Target Daily Emissions itself needs to be input as a time variable. 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. > [@msa6867](#): > > . For v1, I think we need to build the model to allow per-region per-chain RTTM, as I anticipate that being one of the primary research areas the model will be useful for. 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. > [@msa6867](#): > > **Allocation** : For v1 we will need fisherment allocation 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. > [@msa6867](#): > > **App Burn:** For v1 will need AppBurnPerSession and AppBurnPerRelay (which may be fixed or may follow a formula the way RTTM is). For v0, will need some kind of parameter by which to input value of some sort of off-chain burn mechanism For v0 I just used “ABR” but that is not clear enough, it seems like a flag. Maybe we can use [USDRelayTarget](https://forum.pokt.network/t/pup-23-stairway-to-sustainable-economics/3292) and some logic? > [@msa6867](#): > > **Granularity** : I can’t imagine granularity is something to be set. To me it is an upfront design choice that is hardcoded. Session vs day vs month would, I think require different code sets. I would love to see the counter view fleshed out. 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. --- _[View the full topic](https://forum.pokt.network/t/radcad-base-model-discussion/3969)._