2.2. 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

Core Estimation Logic

The core logic behind Xangle ERP's Tokenomics Module is as follows:

In short, Circulating Supply is derived by: (Amount of Tokens Issued on-chain) - (Amount of Tokens Burnt on-chain) - (Amount of Tokens considered to be Non-circulating on-chain)

As mentioned in 2. Circulating Supply Methodology, 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.

Multichain Implementations

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 Schedule Logic

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.

Verification

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 LiveWatch.