How to Reconstruct a Token Unlock Schedule Before You Invest

A pie chart and a few percentages are not an unlock schedule. If you want to know what can move, when, and into whose hands, you need the schedule itself: either the project has published a complete one you can verify field by field, or you have to rebuild the missing parts from its documentation and contracts. This article walks through that reconstruction, one field at a time, and then explains the limits of what the finished picture can tell you.

Start with recipients, not percentages

The first column of your reconstruction is the list of recipients: team, advisors, early rounds, public sale participants, treasury, ecosystem or rewards pools, liquidity provisions. Check the terms attached to each one rather than assuming the chart's categories share a single set of rules. Some recipients may sit under the same schedule and the same release configuration; others may not. That is a fact to confirm, not to infer from the chart.

A percentage without a named recipient tells you nothing about obligations or claim mechanics. If a project's materials describe an allocation without saying who controls it, that is a question for the team rather than a gap you fill with an assumption.

Attach the allocation and the initial release separately

For each recipient, record two numbers: the total allocation and the amount released at the sale or listing event. These are different fields and should not be collapsed into one.

An initial release can coexist with a cliff applied to the rest of the allocation. A cliff is a delay before further vesting eligibility begins. Do not assume the cliff covers the whole allocation just because the documentation mentions a cliff. The cliff scope is its own fact, and you should confirm which portion of the allocation it governs for each recipient.

Map the subsequent release method

After the initial release and the cliff, tokens become available over some schedule. Your reconstruction should say, per recipient, how that happens: over what period, in what increments, and by what method.

For an implementation reference, OpenZeppelin's finance contracts document a vesting wallet that releases assets to a beneficiary on a configurable schedule, with a separate release operation, and an extension that adds a cliff delaying vesting eligibility. That is an example of how vesting can be built, not evidence that a particular project uses it. Read the campaign's own contracts and terms rather than mapping a general pattern onto them.

Treat the claim as its own step

Keep three things apart: the schedule, the amount currently available under that schedule, and the act that actually moves the tokens.

In the OpenZeppelin vesting wallet, release is a separate operation, so availability and transfer are not the same event. Other designs may work differently. Add a column for the mechanics of the transfer: whether a claim is required at all, who initiates it, where, and what a recipient has to do. If you are participating in a sale, verify the eligibility and claim instructions for your own allocation specifically.

Do not read intent into a lock

A long vesting schedule is sometimes read as evidence of commitment. Vesting is a constraint on token movement, and it says nothing about a person's belief, loyalty or future actions.

There is also a structural limit worth knowing. OpenZeppelin's documentation notes that ownership of a vesting wallet can be transferred, which means a token lock does not prove that the underlying economic interest cannot be sold. Whether that applies to any specific project depends on that project's contracts. Locked tokens and locked exposure are different questions.

Separate unlock size from what the market can absorb

An unlock makes tokens eligible to move. It does not establish that the recipient sells, and it does not tell you what price results if they do.

Supply figures and completed volume will not answer the absorption question on their own. Coinbase describes its order book as the current open orders and its depth chart as bids and asks across prices with cumulative size, with trade history shown as a separate view. Completed volume is a record of what already happened, and total supply is a record of what exists. Neither shows the buy orders standing at this moment. Where a token trades on an order-book venue, that venue's current book is one place to look, so identify where the token actually trades before deciding what data to read. Those observations are venue-specific and time-specific, so one snapshot is not guaranteed executable liquidity later.

The honest output of a reconstruction is a schedule of eligibility, plus a list of open questions about behavior and liquidity that the schedule cannot answer.

What projects should publish, and where the Pad fits

If you are on the issuing side, the reconstruction above is also a publishing checklist. For each recipient, state the allocation, the initial release, the cliff and its scope, the subsequent release method and the claim process. Then compare the published terms against the deployed configuration before announcing a date, rehearse the participant claim flow, and document any decision that is still unresolved. These steps aim at reducing ambiguity; completing them does not guarantee a successful or safe launch, and market conditions and external dependencies still apply.

ChainGPT Pad's white-label documentation lists sale configuration, vesting, claims, refunds, KYC-related contracts, a participant dashboard and admin tools, along with development, auditing and testing support. Those are capabilities available to a project, not a description of any given campaign's settings, so the specific schedule still has to be verified campaign by campaign.

If you are planning a token sale and want to walk through how vesting, claims and participant flows would be configured for your launch, book a demo with the ChainGPT Pad team.