A vesting disclosure and a deployed contract are two separate pieces of evidence. To call a schedule verified, I compare the published terms with the code and state that govern releases, then label anything I cannot observe as unknown. This check can establish whether stated mechanics match accessible evidence. It cannot show that an unlock caused a price move or changed user retention. Those are different questions that need different data and research designs.
Find the disclosure and define what it claims
Save the exact source where the project states its vesting terms. Prefer a current tokenomics page, governance proposal, legal filing or dated project document over a repost or community summary. Record the URL, retrieval date, version or publication date, and the wording that describes the allocation. Identify what the schedule covers: a named recipient, a recipient class, a treasury bucket, an investor allocation or all circulating supply. A percentage without a denominator is not a complete claim.
Translate the disclosure into fields you can compare: beneficiary or recipient class, asset, total allocation, start condition, cliff, vesting duration, release cadence, revocability and any transfer or governance controls. Keep the original wording alongside your normalized field. If the project says “team tokens vest over three years,” do not silently convert that into monthly releases. The phrase does not specify a start date, cliff, cadence or whether the allocation is held by one wallet or several.
Separate a planned schedule from observed behavior. A published calendar may describe an intended allocation. It does not prove that the described tokens sit in a specific contract or that no administrative path can change the release. Your notes should identify the evidence layer for each statement: disclosure, verified source code, contract state, transaction event or analyst inference.
Locate and inspect the relevant contract
Find the contract address from an official project source, deployment registry or governance record. Confirm the network and token address. Then check the explorer's verified source and compare its compiler and constructor context with the deployed address. A matching contract name is not enough. Projects can deploy modified contracts, proxies or custom vesting systems that share familiar labels.
OpenZeppelin documents `VestingWallet` as an ownable contract that can release native assets or ERC-20 tokens to a beneficiary according to a customizable schedule. Its documentation also notes that assets sent after vesting begins can be partly releasable immediately, and that ownership can be transferred. These mechanics matter when assessing a deployment built from that primitive. They do not prove that any named project uses an unmodified OpenZeppelin contract. Read the deployed code and configuration for the address you are checking.
For a proxy, identify the proxy and implementation, the admin or upgrade authority, and any implementation changes that apply to the period you describe. For a custom contract, trace the functions that calculate releasable amounts and authorize release. If you cannot verify source code or resolve the implementation, stop short of asserting the exact schedule. Label the contract behavior unknown or partially verified.
Compare release rules with observable state
Compare one field at a time. Does the contract identify the same beneficiary? Is the asset the same token? Does the configured start time match the disclosure's stated start? Do the duration and cliff rules align? Can the recipient or owner change the schedule? Is there a pause, revocation, admin or upgrade mechanism? A positive answer to one field does not verify the whole schedule.
Use on-chain reads and events to confirm what has happened. A contract's current releasable amount is a state observation at a specific block or timestamp. A transfer event is evidence of a transfer, but it may not explain the project's full allocation. Wallet labels on explorers are attribution hints unless the project or another strong source confirms them. If several wallets receive tokens, do not assume they belong to the same disclosed recipient class without evidence.
Record each comparison as supported, contradicted, partially observable or unknown. Include the block number or query time for state readings. Preserve raw transaction links and the method used to identify the contract. If an indexer or explorer is unavailable, do not substitute a guessed result. The Ethereum developer documentation explains smart contracts as programs on a blockchain, but a general explainer cannot verify a particular contract's deployment or state.
Report gaps without inferring intent
A mismatch is a finding about evidence, not proof of misconduct. The published document may be stale, the deployment may have changed, or the wallet attribution may be incomplete. State the exact conflict and the limits of the check. Ask the project to clarify the source of truth when a central term cannot be reconciled. Do not write that tokens are “unlocked” merely because a date has passed; confirm that the contract makes them releasable and distinguish that from an actual transfer.
Keep vesting analysis separate from retention analysis. To test whether user behavior changed around an unlock, define the cohort, observation window, outcome and confounders. A schedule alone cannot establish user churn, token selling or price impact. My related guides on [vesting schedule design](token vesting schedule guide) and [retention after incentives](retention after incentives guide) cover those separate questions.
The final report should let another analyst reproduce the conclusion. Include the disclosure excerpt, contract address, network, source verification state, fields compared, state block, event links, unknowns and the date of the check. If the evidence is incomplete, the honest result is a partial verification, not a binary pass.
OpenZeppelin describes the default `vestedAmount` implementation as linear, while also allowing the schedule formula to be customized. The curve below normalizes time and vested share to make that default easier to read. It contains no project address, allocation size or actual release data. A deployed contract can use a custom schedule, a cliff extension, a proxy or other behavior. Inspect the specific code and configuration before using this shape to describe a project.
Evidence record
| Evidence area | Record | Decision rule |
|---|---|---|
| Source | Official page, address or configuration | Keep the URL and check date |
| Observed behavior | Response, state, function or event | Separate observation from disclosure |
| Uncertainty | Unknown or partial field | Do not fill gaps by inference |
| Owner | Person responsible for resolution | Recheck after any material change |
Frequently Asked Questions
Can a vesting disclosure prove that tokens were released?
No. A disclosure states terms or intent. To confirm an actual release, inspect the relevant contract state and transactions, while verifying that the address and recipient attribution are correct.
Does verified contract source prove the project followed its published schedule?
No. Verified source helps inspect code at an address. You still need to identify the right deployment, its configuration, current state, any proxy implementation and the disclosure scope.
Can a vesting schedule explain token price or user retention?
Not by itself. Price and retention claims need separate data, defined windows and a design that addresses other causes. A schedule establishes neither causation nor outcome.
What if the beneficiary or release rule is unclear?
Record that field as unknown or partially observable. Do not infer a match from a wallet label, project statement or familiar contract name alone.
References
- https://docs.openzeppelin.com/contracts/5.x/api/finance, accessed 2026-11-09.
- https://ethereum.org/developers/docs/smart-contracts/, accessed 2026-11-09.
Make the next decision from evidence.
I review Web3 growth systems across product, distribution and measurement.
Explore the Web3 Growth Audit