Token unlock research: schedule, claim, transfer
A token unlock is a change in a restriction or entitlement, not evidence that someone sold tokens. Research the schedule, the amount currently releasable, the amount actually claimed, and subsequent transfers as separate stages. This distinction is essential when a spot research note discusses potential supply changes without inventing selling pressure.
OpenZeppelin’s Finance documentation describes a vesting wallet with a customizable release schedule. It is a reference implementation, not evidence that an individual project uses that implementation unchanged. Confirm the deployed contract and its configuration before applying any schedule described in a library or announcement.
Reconstruct four stages
Start with the allocation agreement or official distribution explanation. Identify the beneficiary category, token amount, start time, cliff, duration, and whether releases depend on elapsed time or another condition. Calendar graphics often omit details that determine the actual releasable quantity.
Then locate the implementation that enforces the schedule. If the restriction is contractual or administrative rather than onchain, say so explicitly. A team promise and a deployed timelock have different evidence requirements. Record who can modify the schedule, transfer the beneficiary role, or revoke an allocation.
| Stage | Evidence | What it does not establish |
|---|---|---|
| Scheduled | Dated terms and allocation | Tokens have been claimed |
| Releasable | Contract state under current rules | Beneficiary has withdrawn |
| Claimed | Successful release and recipient | Tokens reached a market |
| Transferred | Asset movement to another address | Sale, motive, or final owner |
The useful output is a stage ledger with a separate date and quantity for each transition. Avoid putting all four stages in one column labeled “unlocked.”
Hypothetical cliff and claim example
Assume a fictional beneficiary has an allocation of 12 million tokens. Its verified rules make three million releasable on a cliff date and release the remainder over later periods. On the cliff date, only one million is claimed. A calendar might show a three-million unlock, while the chain shows a one-million transfer. Those observations can be consistent because they describe different stages.
Suppose the claimed million moves to an address tagged as a custodian. The next sentence in the research note should not say a million tokens were sold. The movement may reflect custody, internal administration, or another purpose that the available evidence cannot resolve. Write the observed destination and the uncertainty instead.
If the beneficiary changes before the cliff, preserve that event in the ledger. A schedule that remained identical may now represent a different party’s entitlement. Conversely, a beneficiary remaining unchanged does not establish the absence of a private economic arrangement. The example illustrates evidence boundaries rather than predicting behavior.
Check time and arithmetic
Convert all timestamps to a stated timezone before comparing a calendar with contract state. Check whether a reported date refers to the start of eligibility, an expected claim, or the publisher’s reporting day. Inspect the boundary immediately before and after the release point if historical state is available.
Calculate the releasable amount using the actual schedule, including previously claimed quantities. A cumulative vested amount is not automatically the amount newly available today. Keep cumulative allocation, cumulative vested, cumulative released, and remaining releasable balances in different fields. This prevents a repeated monthly report from counting the same eligible tokens again.
Independently verify a small release or one beneficiary before scaling the method to the entire allocation table. When the implementation is unknown, do not manufacture an exact daily curve from a coarse quarterly announcement. Present the disclosed range and explicitly state that the within-period distribution is unknown.
Limits and common mistakes
Unlock analysis cannot reveal all private transfers, hedges, beneficiary intentions, or offchain restrictions. It may be unusable as a precise schedule if the administrator retains discretionary release power. Common mistakes include treating release eligibility as immediate sale, adding cumulative figures across dates, ignoring schedule changes, and applying a generic library description to a customized deployment without inspection.
FAQ
Which number belongs in an unlock calendar?
Label it precisely: scheduled eligibility, newly releasable quantity, or actual claims. Include the rule and observation time so readers can compare like with like.
Does an unlock prove that supply will enter the spot market?
No. Eligibility and transfers establish only particular stages. Market entry and any resulting price effect need separate evidence that may remain unavailable.