Distributing Owed Amounts - Rebalancing

There are 2 scenarios that must trigger a staking pool owed funds distribution/rebalancing:

1. New stake is made (either to an existing or new slot)

2. Withdrawal is executed

For simplicity, let’s focus on scenario 1, as scenario 2 will be clarified in the withdrawal section below. Sticking with Staking Pool 0 from the example data above, let’s assume a new stake of 100 AOVR is to be made to the empty Slot 2. Since there is an amount of 20 AOVR owing to the pool, at the current state it is clear that Slots 0 and 1 are owed 66.66% and 33.33% respectively. If we fail to distribute the owed 20 AOVR and a new stake of 100 AOVR is added to Slot 2, the owed amount distribution becomes 50%, 25%, and 25% to slot 0, 1, and 2 respectively, leading to the holders of slot 0 and 1 making a loss and slot 2 gaining reward without having staked fund.

Therefore, when a new stake is to be made, and the pool has funds owing, a rebalancing must take place in the following manner:

• An account makes a request to the ovr-program to stake 100 AOVR in Pool 0, empty Slot 2

• ovr-program reads the Staking Pool Registry account data to locate the correct Pool. The address is kjs976jgsjhgs7... is found and a check is made to see that the correct Staking Pool account has been passed into the ovr-program function as it must be written to

  • Note that looking up the pool by the passed-in index moves the work of finding the correct slot off-chain and no looping is required, resulting in fewer transaction costs and computation operations.

• Check whether funds are owing to the pool by reading the owed field.

• If no funds are owing to the pool, the value of 100 AOVR could be written to Stake Pool 0 Slot 2, and the totals on the pool and Staking Pool Registry could be updated. However, there are 20 AOVR owing.

• The ovr-program loops through all slots, and based on their current staked amount distributes the 20 AOVR as described in the balance calculation above (66.66% and 33.33% to Slot 0 and 1 respectively)

• The staked amount of Slot 2 is set to 100 AOVR

• The pool totalStaked is set to 420 (300 total staked, 20 owed, 100 newly staked)

• The pool totalOwed is set to 0

• The Staking Pool Register pool 0 staked and owed values are updated to 420 and 0 respectively

• The Staking Pool Register totalStaked and totalOwed values are updated to 1120 and 180 respectively

The data of Staking Pool Registry and Staking Pool 0 now look like this:

{
    "totalStaked": 1120,
    "totalOwed": 180,
    "pools": [
        {
            "poolAddress": "kjs976jgsjhgs7...",
            "staked": 420,
            "owed": 0
        },
        {
            "poolAddress": "gd63hdhduyus77...",
            "staked": 400,
            "owed": 95
        },
        {
            "poolAddress": "8uye63yehdyt7e...",
            "staked": 300,
            "owed": 85
        }
    ]
}

{
    "totalStaked": 420,
    "totalOwed": 0,
    "stakes": [
        213.33,           
        106.66,
        100,
        0,
        …
        0
    ]
}

Recap: When balances need to change, either with new stakes coming in or withdrawals being processed, only the pool being touched needs to be rebalanced. Once rebalanced, new stakes can simply be written into the Staking Pool Registry and Staking Pool data accounts. This satisfies the requirement of not exceeding a high number of accounts that need to be passed in (only the Staking Pool Registry, Staking Pool and Payer accounts are required), not exceeding too many computations (loops through 100 items) and is atomic.

Who will perform and pay for rebalancing? Rebalancing is a permissionless operation and can be cranked by anyone willing to pay a small transaction fee. When one of the two operations requiring that any pending rebalancing be executed before continuing are called, there are two options that can be chosen:

1. A specific Rebalance function is called first, taking in the pool and slot indexes and rebalancing the pool

2. The stake or withdraw functions do it automatically before proceeding if required

   1. This will be an optional parameter on the functions (do_rebalancing) defaulting to false so that no unexpected transaction fees are incurred.

   2. If do_rebalancing is set to false but rebalancing is required, the operation will fail

Note: ALLOVR Studios could set up a cranking process that calls the Rebalance function for any slots needing it on an interval triggered by a successful inflation run.