Versions Compared

Old Version 102

changes.mady.by.user Eric Butz

Saved on

compared with

New Version 103

changes.mady.by.user Eric Butz

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

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

...

  • since we will permit main net and FIP-6 locks to co-exist (for unstaking only, you still cannot create a lock on an account with existing tokens), we must combine the votable balance computations to provide an accurate votable balance when both types of lock are co-existing in the same account.

...

  • When user unstakes FIO Tokens, the TPID attached to the unstake action receives 10% of the difference between tokens being unstaked and FIO Tokens received as a result of SRP to FIO Token conversion. If no TPID is provided, the 10% remains undistributed.

Requirement: In order for you to stake tokens you must have voted

...

for at least 1 BP or proxying/auto-proxying

  • we must enforce this business rule.

...

  • Epic – FIO staking

    • Stories

      • Produce design spec, and revise FIP-21. (1 week Complete)

        • review internal, and community.

      • FIO Staking Development (3 weeks In progress 85% complete)

        • implement the solution as per FIP-21 and detailed development spec.

          • Started work March 29

          • constants implemented

          • staking global state implemented

          • account staking implementation implemented

          • port existing work to new contract fio.staking, completed

            • make shell of the new contract and integrate into the build.

            • integrate all table implementations for staking into fio.staking contract.

            • integrate stake and unstake shell into fio.staking contract.

          • Develop new logic to permit new contracts and system accounts to be added to the FIO protocol without mandatory core upgrades (completed, in QA for Bahamas)

          • implement and test actions to update global state for staking. In progress (100% completed)

            • implement stakefio (completed)

            • implement unstakefio (completed)

            • implement modified locking mechanism to support unstakefio (completed)

            • impelement and test incgrewards

            • implement and test clrdrewards

            • implement and test recorddaily

          • adapt usable balance logic

          • adapt voting power logic

          • transfer

          • transfer using pub key

          • modify fee collection logic

            • process_rewards

            • processbucketrewards

            • processrewardsnotpic

          • bpclaim

            • bpclaim

          • implement the removal of expired periods during lock adaptation on unstaking.

          • implement the use of an existing period if there is a period in this same day during unstaking

          • Implement new model for general locks, place SUF amount instead of percent.

            • retire old lock tokens and replace with locktokensv2 table.

            • integrate new table throughout contracts and chain_plugin.

        • Dev test. (30% completed)

          • Regression testing (runs of fio.test) completed

          • dev test cases

            • pre existing main net locks (test all unlocking periods using transfer and vote producer) (manual testing completed)

            • pre existing main net locks (test staking and transfer before and after first unlock period) (javascript fio.test integrated testing completed)

            • modify all general locks tests to run with the new v2 general locks table.

            • modify performance tests to use new general locks structure

            • incgrewards

            • recorddaily

            • no pre-existing locks

            • pre existing general locks

            • use existing main net locked account to create general lock

            • pre existing main net AND general locks

        • develop tests matching test plan in design spec.

        • internal code review

        • internal testing review.

        • perform QA and resolve all issues (comprehensive QA analysis)

        • Acceptance testing review by product owner.

      • FIO staking – Security/Performance testing (dev net) (1 week)

        • develop tests to load system and drive volume of requests (we desire a max stakes test, and also a volume of staking unstaking requests once loaded maximally) performance test plan is still TBD.

      • Rollout testing (dev net) (2 days)

        • load previous version of contracts, perform contract MSIGs, repeat load testing.

      • Test net testing – (1 week)

        • roll out msigs, perform subset of functional tests on test net (tests to be performed are TBD)

      • Main net rollout (2 days)

        • roll out MSIGs, perform minimal success testing to verify deployment (tests to be performed are TBD).

  • security of the new locking actions will require relatively complete QA testing (a test plan will be published).

...

  • Update all SDKs to include new endpoints for staking.

  • FIOSdk_typescript

    • integrate stakefio into SDK (6 hours) (completed)

    • expand tests to cover stakefio in SDK (4 hours)

    • Integrate unstakefio into SDK (6 hours)

    • expand tests to cover unstakefio (4 hours)

    • integrate changes to get_balance (4 hours)

    • integrate get_staked_info into SDK (6 hours)

    • expand tests to cover get_staked_info (4 hours)

  • FIOSdk_Kotlin

    • integrate stakefio into SDK (6 hours)

    • expand tests to cover stakefio in SDK (4 hours)

    • Integrate unstakefio into SDK (6 hours)

    • expand tests to cover unstakefio (4 hours)

    • integrate changes to get_balance (4 hours)

    • integrate get_staked_info into SDK (6 hours)

    • expand tests to cover get_staked_info (4 hours)

  • FIOSdk_IOS

    • integrate stakefio into SDK (6 hours)

    • expand tests to cover stakefio in SDK (4 hours)

    • Integrate unstakefio into SDK (6 hours)

    • expand tests to cover unstakefio (4 hours)

    • integrate changes to get_balance (4 hours)

    • integrate get_staked_info into SDK (6 hours)

    • expand tests to cover get_staked_info (4 hours)

...