Links

Design

Questions Re FIP-21

Question

Answer

Would it be useful to provide a getter that will tell the user what the rewards amount will be if they unstake now?

whats your opinion on a getter get_staking_rewards(pubkey, amount) returning a breakdown of the rewards and principle..

I would make it more generic and not pass the amount. Also we may need to add staked tokens in get_balance. Let me spec it. (Still TBD?)

stakefio, unstakefio is bundled, what is the fee when the bundle count is expired?

TBD: do some analysis of the finished implementation and come up with recommend.

What are the specific logistics of daily_staking_rewards, and total_staking_rewards?

The daily_staking_rewards should only be used to understand if tokens for staking rewards needs to be minted. Both the total and the daily should be incremented together in synchrony otherwise.

do we need to have the Rate of Exchange (ROE) stored in state. We can compute it when needed, it looks like everywhere we need it we are reading the state table with the info anyway, so its just a divide computation to arrive at the value.

its fine to use the values that make up this value and compute it on the fly as needed and not store it in state.

What are the units of SRP. should we come up with a units of SRP for this, i also would like to understand if theres any decimal resolution necessary for SRPs (similar to SUFs)..

lets call them SUS (smallest units SRP) and lets use 9 decimals just as we do SUFs.

When a user performs multiple stakings, lets say day one they stake 200 FIO, day 2 they stake 100 FIO, then they call unstake on 250 FIO. is it safe to assume that unstaking will perform logic that looks for the longest duration staking and apply that ROE for the amount to unstake, perform that unstake, then go to the next staking event and apply the remained to that event, and so on until all of the desired amount is unstaked, the final stake will need to be “adapted” so as to remain accurate, in this case the day 2 stake will need adapted to become 50 FIO instead of the original 100.

we just store SRPs which are computed when we stake, these are additively recorded upon staking, and decremented upon unsticking.

we also store the total number of FIO which are staked per account, these are also additively recorded upon staking a dn decremented upon unstaking.

so we need two numbers stored by account total_SRPs and total_staked_fio.

The FIP will be reviewed with this in mind and we will attempt to clarify this at the FIP level.

Some clarity is needed regarded what to do when there are locked tokens (Mainnet locks, and general locks)

if an account has genesis locked tokens or General (FIP-6) locks are they prohibited from staking?

Accounts are never prohibited from staking.

if the account has main net locked tokens, then the user may stake and unstake the unlocked portion of those tokens in that account (all unlocked tokens are eligible for staking, and should stake and unstake as expected).

if the account has general locked tokens, then the user may stake and unstake the unlocked portion of those tokens in the account (all unlocked tokens are eligible for staking, and should stake and unstake as expected).

the FIP will be examined to see if clarification can be added.

RAM increment amounts are not specified for the actions in this FIP please add details for RAM increment amounts

these will be computed during development, and updated into the FIP a place holder will be added for this.

Add a line in the implementation of actions to check for max FIO transaction size exceeded.

this will be added to the FIP

Design Approach/Overview

New Constants (dev complete 3/29/2021)

Constant values will be added to the system for the following items:

COMBINED_TOKEN_POOL_MINIMUM – this will be set to 1,000,000,000,000,000 FIO SUFS

STAKING_REWARDS_RESERVE_MAXIMUM – this will be set to 25,000,000,000,000,000 FIO SUFS.

New Table

We will create a new table in state called the global staking info info this will have the following attributes.

staked_token_pool –

this will be the total FIO tokens staked for all FIO users.

(units FIO SUF)

combined_token_pool –

this will be the total FIO tokens staked for all FIO users plus the staking rewards for all FIO users.

(units FIO SUF)

rewards_token_pool –

this is the amount of rewards collected from fees plus the amount of rewards minted. it is also the amount of rewards available for all of the fio accounts with staked tokens.

(units SUFs)

global_SRP_count –

this is the global SRP count used to compute the rate of exchange for staking rewards.

(Units SUS)

total_staking_rewards –

this is the value of the total staking rewards

(units SUFs)

daily_staking_rewards –

this is the value of the staking rewards per day.

(units SUFs)

staking_rewards_reserve_minted –

this is the amount that has been minted so far for rewards.

(units SUFs)

Requirement: Storing the values of the total_SRPs, and the total_staked_fio by FIO account

There are a couple of approaches to this which should be considered:

Approach #1: Binary Extension of eosio_name/accountmap

The accountmap table already exists within the FIO Protocol. This table can be extended using binary extenstion to add a new attribute called rate_of_exchange.

advantages – no duplication of account in state tables.

disadvantages –

migration issues after update.

testing after the binary extension is very important, after the deployment of the binary extension, the table entries that have not yet set the value of this new attribute will not return the new attribute in the return data using get table, we must test scenarios where an account has been updated to the new table struct, but has not yet done staking, and then calls unstake, we must also test these updated accounts for staking.

Approach #2 (PREFERRED): Create new table with mapping for accounts that stake:

This approach would create a new table called user staking, this table would contain entries for accounts that have staked. when an account unstakes, the entry for that account would be removed from state.

Each user staking record has the following attributes.

dis-advantages – this approach duplicates the account info in state for accounts that stake.

advantages –

this approach only stores staking records in state for staking events for accounts, accounts that do not stake will not have any additional state information associated with the account.

this approach has no migration issues since a new table is created to hold the staking info for accounts.

this approach does not impact the account map or other areas of fio.

Requirement: lock tokens for existing accounts.

We must design a means for the FIO Protocol to perform 2 operations which it does not today:

1) add general locks to a pre-existing FIO account.

The initial thought on this is to make a new contract action that does the job of creating a lock on a pre-existing account, this should only be callable contract to contract (authorization checks should prohibit other callers from calling the action).

2) modify pre-existing lock information to properly record the resulting locks whenever unstaking occurs.

The initial thought is to make a new action addlockperiod which will only be callable contract to contract, (authorization checks should prohibit other callers from calling the action).

We need to do some optimized form of the following logic:

Check to see if the account has Main net locks.

  if (main net locks exist) 

              {

                 Check to see if the account has a general lock (fip-6) already.

                 if (general locks exist)

                 {

                      adapt the lock amount, remaining lock amount, and lock periods to add the new 7 day lock.

                 }

                else

                 {

                     verify the remaining locked amount in the account. (amount in account - main net remaining locked >= amount to lock)

                     make a new general lock with one seven day period.

                 }

             }

             else  if main net locks do not exist.

             {

                 Check to see if the account has a general lock (fip-6) already.

                 if (general locks exist)

                 {

                      adapt the lock amount, remaining lock amount, and lock periods to add the new 7 day lock.

                 }

                else

                 {

                       make a new general lock with one seven day period.

                 }

             }

Requirement: Accumulate and manage staking rewards

Proposed:

Requirement: Perform fee accounting, and new BP claim logic to manage staking rewards (including minting)

Proposed:

Requirement: Compute the usable balance accurately when an account has staked tokens.

Proposed:

Requirement: staked tokens count towards votable balance.

Proposed:

Requirement: staked tokens cannot be used to pay fees.

Requirement: TPIDs will receive a percentage of the Fees AND part of staking rewards.

Requirement: TPIDs will receive a percentage of the Fees AND part of staking rewards.

Requirement: If auto proxy is used in the staking call, the code should not fail voting checks if this is the first call using tpid (when the auto proxy is being established IN the staking call).

Summary of changes to fio and fio.contracts

Summary of FIO core changes.

In order for new contracts to be added to the Fio Protocol, the FIO core code must be modified to add new system accounts to the list of system accounts. This is somewhat limiting and forces the systems core code to be upgraded by all BPs, integrators, exchanges, and API node operators. The solution to this is to provide enhancements to the FIO core so that the system uses the contract names in the actions table to determine the list of system accounts. These changes will be developed and delivered before this project delivers, and this will remove the need for future mandatory upgrades for projects introducing new contracts and system accounts (such as wrapping, marketplace, and any others that come about).

Actions and Endpoints

Structs and ABIs

Tables

Project Plan

color key

(blue items – in progress)

(green items – completed)

(black items – to be completed)

Risks

SDK Requirements

Functional Testing

Design

Results

Performance Testing

Design

Results

Fork Testing plan

Rollout/Release plan

Rollout/Release verification plan

Branching Strategy/Code logistics

Project Progress