Methodology
This section will mostly elaborate on the core circulating supply estimation logic, and verification methods to compare the project’s planed unlock schedule to the project's actual distribution status
Last updated
This section will mostly elaborate on the core circulating supply estimation logic, and verification methods to compare the project’s planed unlock schedule to the project's actual distribution status
Last updated
The core logic behind Xangle ERP's Tokenomics Module is as follows:
As mentioned in , the above method assumes Tokens existing on-chain (Total Supply) to be in a circulating status by default. This gives responsibilities on the project side to prove non-circulating supply, with a design ethos prioritizing investor protection.
However, different on-chain / off-chain scenarios is very likely to occur within a token’s life cycle: supporting multi-chain environment requiring token management in a multichain environment, tokenomics changes resulting in adopting inflationary mechanics, even changes in previously published unlock schedules.
To simply put it, token management even on multi-chain environment is just multiplication of circulating supply estimation logic per each chain in utilization - unless lock-and-mint bridges are used. While it is recommended that projects use a burn-and-mint bridges or AMB(Arbitrary Messaging Bridges) supported by multi-chain token standards, lock-and-mint bridges require additional steps for accurate estimation: (1) Amount locked on the source chain needs to isolated from those already circulated and (2) Such amount then can be considered as a non-circulating supply.
Unlock Schedules are time-series data representing project's distribution plans. Many token projects currently utilize two types of unlock schedules: (1) Categorized Unlock Schedules (via allocation categories) and (2) Total Unlock Schedules (via sum of all allocation categories)
In addition, unlock schedules can be converted to reserve schedules, which signifies amount of tokens the project plans to hold in its control during token's life cycle.
While token projects initiate projects with pre-minted tokens at the TGE (Token Generation Event), in operation, necessity of verification between its schedules and actual reality may arise either from the community, regulators, or even the project itself for risk management purposes. Verification can occur in various perspectives: starting from total unlock schedule, via allocation categories, and even at the wallet level if close inspection is required. Ongoing example by Xangle is.
