> ## 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. # Point-in-Time Data > Unlock schedules as they were known at a past date, dated to when the market could know them # Overview ## The problem: today's schedule hides what was known then A token's unlock schedule changes over time. Projects add releases, cancel them and move them to new dates, usually after a governance vote or an announcement. The schedule you see today already includes every one of those changes. That is a problem when you study the past. If you backtest on today's schedule, your model knows about decisions that had not been made yet. This is look-ahead bias, and it makes past results look better than they were. Dating each change by when Tokenomist published it does not fix this. We often record a change days or months after the project announced it, so a backtest dated by our publish date sees decisions late. ## Our solution: point-in-time data **Point-in-time (PIT) data** is a token's unlock schedule as it stood at a past date, built only from the project decisions that were public by that date. We keep every version of each token's schedule. Each version is dated to when the project made its decision public, not to when we recorded it. When you ask about a date, you get the version that was in force on that date. # Methodology ## Definitions | Term | Definition | | - | - | | **Point-in-time (PIT) data** | A token's unlock schedule as it stood at a past date, including only the project decisions that were public by that date. | | **As-of date (T)** | The past date you ask about. In the API, this is the `asOf` parameter. | | **Look-ahead bias** | Using information that was not available at the time you are studying. Point-in-time data removes it from unlock schedules. | | **Project decision** | A change the project makes public: a new release, a cancelled one or a re-dated one. It usually comes from a governance vote, a blog post or an announcement. | | **Project version** | The unlock schedule from one project decision until the next. It starts when the decision became public (`validFrom`) and ends when the next version starts (`validUntil`). | | **Correction** | A fix Tokenomist makes to data that was public all along, such as a date, an amount or a precision. A correction never opens a project version. | ## How we build project versions 1. **Every project decision opens a version.** The version starts when the decision became public, so it is in force from the moment the market could know about it. 2. **We date each decision from its source.** We use the time stated in the vote or announcement, the on-chain voting end of a governance proposal, the time in the announcement's link, or the first web archive capture of the announcement. If we find no dated announcement, the version starts on its first publish on Tokenomist, the latest date it could have become public. See [how a project version is dated](https://docs.tokenomist.ai/api-documents/point-in-time/overview.md#how-a-project-version-is-dated). 3. **Our corrections are folded in.** A correction is applied to the project version it follows instead of opening a new one, so it never shows up as a change in the project's schedule. 4. **The timeline starts at our first record.** A token's first version is its first version in our records, dated like any other version, not its launch date. ## Known at T vs happened by T A point-in-time answer combines two kinds of information: * **Known at T:** the schedule. Releases dated after T are still returned, because they were the forecast at T. * **Happened by T:** amounts and claims. Unlocked and locked supply are evaluated on T's UTC day, so a release dated later that day already counts. Only claims made on or before T are included. USD values are left out, because prices after T would leak hindsight. # Example case Token X is a made-up token. Its dates show how versions are built and which one you get for a given date. | Date (UTC) | What happened | | - | - | | 2025-01-10 | Tokenomist publishes Token X's launch schedule. The team allocation unlocks in one cliff on 2026-01-10. | | 2025-03-15 | Tokenomist corrects an investor unlock amount that was entered wrong at launch. | | 2025-06-02 14:00 | A Snapshot vote closes and moves the team cliff to 2026-07-10. | | 2025-08-20 | Tokenomist publishes the new team cliff date. | This gives Token X two project versions: | Project version | `validFrom` | `validFromBasis` | Team cliff | | - | - | - | - | | 1 | 2025-01-10 | `first_published` | 2026-01-10 | | 2 | 2025-06-02 14:00 | `stated_in_document` | 2026-07-10 | * The correction on 2025-03-15 does not open a version. Version 1 serves the corrected investor amount. * Version 2 starts on 2025-06-02, when the vote closed, not on 2025-08-20, when Tokenomist published it. What you get for each as-of date: | As-of date | Version returned | Team cliff returned | | - | - | - | | 2024-12-01 | None. The API answers `404 NO_VERSION_AT_AS_OF`. | None | | 2025-05-01 | 1 | 2026-01-10 | | 2025-07-01 | 2 | 2026-07-10 | | Now (no `asOf`) | 2 | 2026-07-10 | On 2025-07-01, Tokenomist still showed the old cliff date. The vote was already public, though, so point-in-time data returns the new date. That is what the market could know on that day. # Access Point-in-time data is available through the [Point-in-Time History API](https://docs.tokenomist.ai/api-documents/point-in-time/overview.md): * [Token versions](https://docs.tokenomist.ai/api-documents/point-in-time/versions.md): every project version of a token, with its dates, what changed and the sources. * [Allocations as of a date](https://docs.tokenomist.ai/api-documents/point-in-time/allocations.md): the allocation table, with unlocked and locked amounts at T. * [Daily emission as of a date](https://docs.tokenomist.ai/api-documents/point-in-time/daily-emission.md): the daily emission series as known at T. * [Unlock events as of a date](https://docs.tokenomist.ai/api-documents/point-in-time/unlock-events.md): cliff unlock events as known at T. Your plan decides which endpoints you can call and how far back T can go. # FAQs **Why not date each change by when Tokenomist published it?** We often publish a change days or months after the project announced it. If you date changes by our publish date, your backtest sees decisions later than the market did. **Do Tokenomist's own corrections create new versions?** No. A correction fixes data that was public all along, so it is folded into the project version it follows. Only project decisions open versions. **Can a past version change?** Yes. A version can change without getting a new id, when we fold a correction into it or establish the date of its decision. **Why are USD values missing?** Prices after T would leak hindsight. To value a past unlock, combine the amounts with your own price data as of T. **Why do I get `NO_VERSION_AT_AS_OF` for an early date?** A token's timeline starts at its first version in our records. Before that version's `validFrom`, no version was in force. The error returns `earliestValidDate`, which you can send back as `asOf`. # Next steps > [card] [Point-in-Time History API](https://docs.tokenomist.ai/api-documents/point-in-time/overview.md) > > Version selector, response metadata, errors and plan access. > [card] [Precision and Assumption](https://docs.tokenomist.ai/methodology/precision-and-assumption.md) > > How we label the source and timing precision of each release. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.