​

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

​

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.
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. This gives Token X two project versions:

• 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: 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:

• Token versions: every project version of a token, with its dates, what changed and the sources.
• Allocations as of a date: the allocation table, with unlocked and locked amounts at T.
• Daily emission as of a date: the daily emission series as known at T.
• Unlock events as of a date: 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