Tokenomics and unlocks: reconcile supply, schedules and claims

1. Define the token and the units

Record the network and full token contract address before comparing supply figures. Under ERC-20, totalSupply and balanceOf expose different quantities, while decimals describes how a supported decimal display is scaled. The standard treats the decimals metadata method as optional. Check the actual deployment and the provider's treatment of its values.

Keep raw integer amounts separate from display amounts in a worksheet. Record the observation block or time and the source of each figure. A difference in decimal handling can make two reports appear to describe very different supplies even when they refer to the same underlying amount.

2. Map the published allocation

Collect the project's official allocation document and its revision date. List each category, its stated amount or percentage, its recipient or controlling arrangement where disclosed, and the evidence for any lock. Check whether percentages use the same supply denominator and whether the categories describe the same point in time.

Record total supply, maximum supply where one is defined, and any circulating-supply figure separately. For circulating supply, capture the source's inclusion rules. A contract balance can show where tokens sit, while the decision to classify those tokens as circulating may require additional assumptions.

3. Read the release mechanism

For each allocation, identify the start time, any initial release, cliff, release frequency and end condition. Translate written dates into a consistent timezone and check whether the schedule is time-based, milestone-based or conditional on another event. Preserve the original wording beside the normalized worksheet.

If vesting is enforced by a contract, identify its address, beneficiary, funding and administrative controls. OpenZeppelin's VestingWallet is one documented example of configurable token release. Its behavior illustrates why the actual implementation and parameters matter; the name 'vesting' alone does not specify a schedule or prove that an allocation has been funded.

4. Calculate releases with explicit assumptions

Use a simple illustrative check: an allocation of 1,000 tokens released in ten equal installments would imply 100 tokens per installment, assuming no initial release, different first installment or other condition. A cliff describes a waiting period, but the amount available when it ends depends on the schedule. Verify that detail before filling a calendar.

Reconcile the installment totals with the allocation, keeping rounding and final residual amounts visible. Separate tokens scheduled to become releasable, tokens already claimed and tokens still held by a release contract. These are different observations, even when a dashboard groups them under an unlock label.

5. Check who can change the assumptions

Review disclosed minting, burning, upgrade and permission-management powers. Find the relevant controlling accounts and any stated delay before a change can take effect. OpenZeppelin's access-control documentation explains common roles; use it to frame questions about a particular deployment rather than assuming every project uses that implementation.

For a changed schedule, preserve both versions and the announcement date. Identify whether the change is a documentation correction, a governance decision or a deployed contract change. An unresolved discrepancy between a calendar and a contract should stay visible until there is evidence explaining it.

6. Report the schedule and its limits

Publish a concise record of the allocation, release mechanism, source dates, relevant contracts and remaining unknowns. A scheduled release does not establish that recipients will claim, transfer or sell tokens, and a transfer does not establish a particular market outcome. Keep those behavioral assumptions separate. The result is a schedule another researcher can check, without presenting a price forecast or an investment recommendation.