Locked tokens overstated (est. 4,300,000 as of 09/22/2020): it assumes tokens of lock type 2 unlock based on predefined time period, but in reality they also have to have the unlock inhibit flag flipped to be unlocked and many of them do not have the flag flipped yet.
Locked tokens understated (est. <50,000 as of 09/22/2020): it does not properly consider tokens spent on fees, which is allowed even if tokens are locked. This primarily impacts tokens of lock type 4 which are seen as permanently locked, even though almost 500,000 have entered circulating supply and then been re-locked in BP rewards and are released every day.
After October 21st, 2020
Locked tokens overstated: tokens of lock type 2 and for which unlock inhibit flag has not been flipped will not be considered 100% locked as they should. They will continue to unlock based on predefined time period.
Number of predefined schedule time periods which have passed
Type of lock
Integration flag determines if FIO Member has launched integration
Remaining locked tokens
Date when locks set (Mainnet)
It is worth noting that the remaining_locked_amount is only updated when the account is subject to an action impacting token balance such as:
Therefore in its current state, sum of remaining_locked_amount is not a good way to calculate locked tokens, because if a predefined time period passes, the amount will not be automatically updated. That’s why time is used in existing calculations.
An enhancement to the FIO Protocol could be be made to create a new maintenance call, which would recalculate locked tokens for every account in locked token table for both Mainnet locks and FIP-6 locks.
Locked token balance could be obtained on-chain by simply summing remaining_locked_amount for both Mainnet locks and FIP-6 locks.
This may involve a lot of calls to process, especially since FIP-6 does not put a limit on number of accounts that can have locks or how many time periods they can have.
Processing would not be instantaneous and therefore locked token numbers would potentially be inaccurate before all processing is complete.
Custom logic could be built on existing Graphana stats service or similar which would properly report locked tokens: