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

<figure><img src="https://695257229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAiV8rQPRMYfCyYrQgX5Q%2Fuploads%2FPUtdo3mgaejGEMs6oT6M%2Ftoken-page-precision-and-assumptions.png?alt=media&#x26;token=7e774bfb-7c0f-4cdd-987f-4db953ff7633" alt=""><figcaption></figcaption></figure>

## 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="<https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAiV8rQPRMYfCyYrQgX5Q%2Fuploads%2FfONX0pmyGeceWx7NcnnW%2Ftoken-page-precision-and-assumptions.mp4?alt=media&token=90139144-9ae6-417a-9ba7-1cb7a988819e>" %}

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