Attributes
- Author(s): @adam and @Olshansky
-
Parameter:
RelaysToTokensMultiplier
,ProposerAllocation
,ServicerAllocation
- Current Value: Variable (see PUP-13: Initial WAGMI Parameters )
- Related: PUP-11: WAGMI Inflation , PUP-14: Increase MaxValidators to improve economic security , PUP-17: The Phase Plan, PIP-22 - Weighted staking, and PIP-23 -Stake Weighted Algorithm for Node Selection (SWANS)
- Replaces: PUP-13: Initial WAGMI Parameters
- New Value: Variable: see below.
Preface
This model was co-developed by @adam and @Olshansky while PUP-15 was still in development.
This was originally intended to be a longer-term solution, but with many other more complex proposals being published, we wanted to share it and get feedback from the community.
tl;dr What do I do?
1. Toggle Around
You can head to this colab, and make a copy by clicking File -> Save A Copy In Drive
.
Play around with the toggles and find parameters you believe create a win-win situation for the Network.
2. Review The Math
Read through the description in this research post, as well as the additional resources in the colab to verify and understand the math for potential missing gaps.
3. Consider Contributing
For or contribute to the colab saved here: GitHub - Olshansk/pockenomics: Pocket Tokenomic Related Research.
Target Validator Stake
This model aims to set a target validator stake in order to secure the network. Intentional byproducts taken into consideration is the goal of optimizing the number of nodes on the network, while not limiting its growth.
Example
Assume there is a total of 100 POKT staked on the network.
A target_val_stake
of 0.8
would imply:
-
80 POKT
is staked across all of the validators (in total) -
20 POKT
is staked across all of the servicers (in total)
Sigmoid
In order to create a smooth and elegant incentive curve with GREAT VIBES, we a sigmoid function is used:
y = \frac{a}{1 + e^{-b(x-c)}} + d
where:
-
a ∈ [0, 1]
: % range (min and max) of the validator rewards (i.e.validator_allocation_range_a
) -
b ∈ (0, ∞)
: Parameter determining the steepness of the curve (i.e.curve_steepness_b
) -
c ∈ (0, 1]
: % target validator stake (i.e.target_val_stake_c
) -
d ∈ [0, 1]
: % min validator allocation of total rewards (i.e.min_val_allocation_d
)
Note: We are omitting some complexities encapuslated by the computation below. For example, a + d ≤ 1
.
If approved, c & d
would be parameter variables set, and periodically modified, by the DAO whereas a & b
are likely to remain constants, though still configurable, based on the community’s discussion.
Network Params & Variables
In addition to the variables above, there are several other parameters that need to be taken into modelling considerations.
-
num_validators
: The # of Validators should be sufficiently high so as to increase security, but not too high due to technical limitations. -
pokt_per_servicer
: The minimum amount of POKT a servicer or validator needs to stake.- Context: Servicers have no incentive to stake far beyond the minimum to earn rewards and are therefore assumed to stake the min in this analysis. However, validators are selected based on a weighted round-robin algorithm from the top 1,000 list and therefore have an incentive to periodically “top-up”.
-
num_nodes
: The total # of nodes (validators & servicers) staked on the network.- Context: This will vary based on market conditions, supply & demand curves, as well as the incentivization curves.
-
total_pokt_staked
: The total amount of POKT staked on the network.- Context: This will vary based on the number of nodes, market conditions, supply & demand curves, as well as the incentivization curves.
- For each servicer that is added or removed on the network, anywhere between 0 and
pokt_per_servicer
will be added / removed to the network for modelling purposes.
-
INFLATION_PER_NODE
: Out of scope for this discussion. Based on WAGMI, this is approximated to 14000 / node staked on the network.
What are we optimizing for?
Inspecting the Ideal % APY vs Num Nodes
graphs below, it shows the general curve we are aiming for:
-
When the number of nodes is high => we are incentivizing the network to contract and move POKT from servicers to validators because we have a small number of validators maintaining the securiry of a high number of servicers until some point.
-
When the number of nodes is low => we are incentivizing the network to expand and move POKT from validators to servicers because we have a small number of validators maintaining the securiry of a small number of servicers until some point.
There is no target number of nodes on the network, but rather a target_val_stake_c
to achieve some level of security, alongside other internal, external, rationale and irrational parameters driven by market supply & demand curves.
Assuming this logic holds, the cost function we are trying to optimize for is the delta between the ideal validator APY
and the ideal servicer APY
.
New Parameter: percent_unstaked_pokt_remaining
Introducing percent_unstaked_pokt_remaining
: For every servicer that is unstaked, how much of the POKT unstaked remains in the network (i.e. is moved to a validator).
For example, if a servicers with 15,000 POKT
staked is unstaked:
-
Is 7500 moved to a validator 7500 is either HODLed / sold?
-
Is all 15000 moved to a validator?
-
Is all 15000 HODLed / sold?
This is too hard to predict and is a function of too many parameters, both rationale and irrational. Therefore, a configurable nob is added for modelling purposes.
Example 1
One potential model of the network and parameters we can set is this:
Example 2
Using a root mean square error optimization, we came up with this: