...
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.
...
Solutions Considered
On-chain
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.
...
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.
SELECTED: Off-chain
Custom logic could be built on existing Graphana stats service or similar which would properly report locked tokens:
...
Data on-chain may not be accurate to outside observer who does not understand the details behind how table values are computed.
Solution Specification
Circulating Supply Service
Existing Circulating Service needs to be modified to accurately compute locked tokens:
Tokens locked via Mainnet locks
Inspect each account in lockedtokens table and apply the same logic used by chain
Tokens locked via FIP-6 functionality
Inspect each account general_locks_table and apply the same logic used by chain
Grafana import
A data feed to Grafana should be generated which feeds current and future tokens locked and divided into the following categories:
Mainnet locks: Type 1
Mainnet locks: Type 2
Mainnet locks: Type 3
Mainnet locks: Type 4
FIP-6 locks
Since it’s difficult to recreate circulating supply historical data, Grafana reports should only include future unlock amounts based on time periods only. For lock type 4, a average number of tokens unlocked in previous 30 day period should be used instead.