> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokenomist.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Precision and Assumption

# 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.

<Frame>
  <img src="https://mintcdn.com/daosurv/0bLtGuoa1l-re1Fs/images/image-20.jpg?fit=max&auto=format&n=0bLtGuoa1l-re1Fs&q=85&s=b0e3d8672a1416436ae4ed39ae695114" alt="Image" width="2304" height="1275" data-path="images/image-20.jpg" />
</Frame>

# 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).

# Access Features

<video src="https://mintcdn.com/daosurv/rWmB7ugbAmnk4eQ5/videos/precisionandassumption-access.mp4?fit=max&auto=format&n=rWmB7ugbAmnk4eQ5&q=85&s=a30da00f4c00b7bd46a7a07ab9e95203" controls={true} data-path="videos/precisionandassumption-access.mp4" />

The Precision & Assumption framework is used across the following Tokenomist features:

* [**Overview Pane**](/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` + `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.