# Precisions and Assumptions
## 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 Contract` with 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 Data` with 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 Data` with precision **Day** (if the team specifies exact dates, but not timestamps).
## Accessing Precision & Assumption
You can find the Precision & Assumption details on every token page. It is located in a dedicated **Tokenomics Reference** section underneath the release schedule that clearly displays the source and precision for each of the token's allocations.
{% embed url="" %}
## Using Precision & Assumption
**1. Evaluate Reliability of Unlocks**
* A **Cliff Unlock** for an *Investor* allocation with a `Vesting Contract` + `Second` precision is highly reliable, near-certain.
* An unlock with `Inferred On-chain` + `Month` precision is far less reliable and should be treated cautiously.
**2. Compare Allocations Across Sources**
See how different allocations within a project vary in reliability — some may be contract-verified while others are only privately confirmed.
**3. Incorporate into Risk Assessment**
Before acting on vesting data, always check its **Assumption** and **Precision** to gauge confidence.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.unlocks.app/methodology/precisions-and-assumptions.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.