PUP-15+: GREAT VIBES - A Sigmoid Based Economics Policy for Pocket Network

Attributes

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.

great_vibes

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.

download

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:

  1. 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.

  2. 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:

4 Likes