Overview
The Problem: Unlock Data Lacks Consistency
Crypto projects report release schedules without any standardized enforcement. Data can be spread across blog posts, whitepapers, on-chain contracts, and multisigs, leading to ambiguity and making it difficult for users to trust the information they find.Our Solution: Precision & Assumption
We introduce the Precision & Assumption framework. For every token we track, we show you where our data comes from (Assumption) and how accurate its timing is (Precision). This framework gives you the clarity to assess the transparency of a release schedule.
Methodology
Definitions
- Assumption (Data Source Types): Indicates where the release schedule data originates.
- Precision (Release Time): Indicates how precise the release timing is.
Assumption (Data Sources)
| Source Type | Definition |
|---|---|
| Public Project Data & On-chain Verified | The release schedule was publicly announced by the project and verified by us on-chain. |
| Public Project Data | The release schedule was publicly announced by the project (e.g., in a blog post). |
| Vesting Contract | The release schedule is derived directly from a time-lock smart contract. |
| Private Project Data | The release schedule was confirmed privately by the project’s team. |
| Inferred On-chain | The release schedule is interpreted by our team from on-chain behavior. |
Precision (Release Timing)
| Precision Level | Definition |
|---|---|
| Second | The release occurs at the exact second specified. |
| Block | The release is tied to a specific block number. |
| Hour | The release can occur at any time within the specified hour. |
| Day | The release can occur at any time within the specified day. |
| Week | The release can occur at any time within the specified week. |
| Month | The release can occur at any time within the specified month. |
| To Be Determined | The release time is not yet known (see TBD Locked Supply). |
Example Cases
Example 1: Vesting Contract with Exact Timestamps
- Scenario: A vesting contract is deployed on-chain with parameters specifying exact unlock times down to the second (e.g.,
2025-01-01 00:00:00 UTC). - Analysis: Because the contract itself dictates the precise timing, the data source is both transparent and verifiable on-chain. Users can independently confirm the schedule without ambiguity.
- Our Categorization:
Vesting Contractwith precision Second (the unlock will execute exactly at or very close to that timestamp).
Example 2: Whitepaper with Monthly Unlocks
- Scenario: A whitepaper states that 10% of tokens unlock “monthly” (e.g., January, February, March) without specifying days or hours.
- Analysis: The data is official, but without finer time granularity. The unlock could occur on the 1st, 15th, or 30th of the month.
- Our Categorization:
Public Project Datawith precision Month (the unlock can occur at any point during the specified month).
Example 3: Private Confirmation from Project
- Scenario: The team privately shares aspects of their vesting schedule with Tokenomist but does not publish it publicly.
- Analysis: While the source is direct, it lacks public verifiability. Confidence depends on the team’s reliability rather than on-chain guarantees.
- Our Categorization:
Private Project Datawith precision Day (if the team specifies exact dates, but not timestamps).
Access Features
The Precision & Assumption framework is used across the following Tokenomist features:- Overview Pane — Every token page includes a Tokenomics Reference section that displays the Assumption and Precision tags for each allocation.
Using Precision & Assumption
1. Evaluate Reliability of Unlocks- A Cliff Unlock for an Investor allocation with a
Vesting Contract+Secondprecision is highly reliable, near-certain. - An unlock with
Inferred On-chain+Monthprecision is far less reliable and should be treated cautiously.