Dropstab
Dropstab token unlocks show release timing within allocation schedules
Dropstab token unlocks show scheduled token releases, their allocation context, and the amounts recorded as locked or unlocked supply. They help answer when a release is expected and where it belongs within a token’s distribution. A schedule describes planned availability; it doesn’t establish that recipients sold tokens or that a price move came from the release. The useful interpretation connects the event date with its allocation and the supply basis used to describe its size.
What can an unlock schedule show about future supply?
An unlock schedule connects planned token availability with allocation information, showing how a release fits into the distribution that extends before and after it. The calendar emphasizes event timing, while a vesting view explains the release pattern.
Vesting describes the rules and timeline for releasing tokens. A cliff delays availability until a specified point; linear vesting spreads releases evenly over its stated period. The applicable pattern belongs to the allocation concerned, so separate categories can follow different timetables.
A future event identifies a planned release. A past entry locates an event on the historical schedule, without establishing a recipient’s subsequent transactions.
Those views support different questions. The next date helps locate an upcoming supply event. The wider timeline shows whether that event sits within a continuing release pattern or concerns an allocation whose schedule is nearing completion.
From token selection to a supply interpretation
Reading an upcoming release starts with the correct token record, then relates the event to its allocation and supply base. The next-release amount describes one event; the remaining locked balance describes tokens still subject to that allocation’s schedule.
| Research stage | Information to use | Supported outcome | Limit of the conclusion |
|---|---|---|---|
| Identify the token | Asset record and available unlock coverage | Schedule matched to the intended token | A matching name alone doesn’t establish identity |
| Locate the release | Event date and scheduled token amount | Timing and size of the planned event | A future entry doesn’t confirm execution |
| Read its allocation | Allocation category and locked or unlocked amounts | Release placed within that allocation’s schedule | One allocation doesn’t describe every holder |
| Interpret its scale | Event amount and a clearly named supply base | Release size relative to that supply base | The ratio doesn’t measure selling or liquidity |
Allocation totals and release amounts describe different scales
An allocation total describes a category’s share of the distribution, while the next-release amount describes the portion scheduled to become available at that event.
Dropstab’s token-unlock data includes allocation-level information on locked and unlocked supply. These figures connect the schedule’s individual entries to the category they belong to. A remaining locked amount can cover later releases beyond the next event, depending on that allocation’s timetable.
A category can describe a team, investor group, or ecosystem allocation. Such labels identify the purpose or recipient class assigned to that part of supply. They don’t establish an individual wallet’s present balance, the recipient’s intention to sell, or the eventual use of every released token. An event affecting one allocation doesn’t automatically describe the other categories. Category totals help show how concentrated the scheduled distribution is.
Funding rounds add financing context when the release concerns an investor allocation. The financing event and its release schedule answer different questions: how a project raised capital, and when the relevant tokens become available.
Release size and market impact require different evidence
Token units measure the scheduled release, while its estimated dollar value changes with the price used to value those units.
A supply percentage also needs a denominator. A share of total supply differs from a share of circulating supply. The same token amount can produce different percentages against those bases, so percentages with different labels aren’t interchangeable. A value relative to market capitalization answers another scaling question; market capitalization doesn’t measure the orders available to absorb a sale. A token amount and its denominator must refer to the same asset and a compatible observation period. A later price can change the displayed dollar estimate even when the scheduled token amount stays unchanged.
Unlock information describes potential availability. A release doesn’t demonstrate that recipients sold, and its estimated market value isn’t a forecast of sale proceeds. Explaining a price move requires evidence about actual trading and demand during the relevant period.
Coverage gaps limit supply conclusions
Missing unlock data leaves a coverage question unresolved; it doesn’t establish that a token has no remaining vesting or that its distribution has finished. The commercial API maintains a separate list of tokens with available unlock data. General market-price coverage therefore shouldn’t stand in for schedule coverage. A partial allocation view can still answer a narrow release question, while a claim about the entire remaining supply requires coverage broad enough to support it.
Visual schedules and API records suit different tasks
The visual schedule suits inspecting a release in context, while the commercial API provides structured unlock and vesting data for repeated analysis in software.
JSON responses make schedule information reusable in an application or a separate chart. The documented unlock datasets cover an overview, per-token details, supported tokens, and chart data. Keys authenticate requests, with dataset permissions and request allowances set by the subscription. A subscription therefore needs to cover the particular unlock data that the application requires.
A separate chart needs to preserve the difference between an event amount and an allocation total. A chart series represents release timing over time; allocation details explain the categories behind that timing. Combining them shouldn’t erase their different scopes or imply that an amount scheduled for release has already reached a recipient.
For one scheduled event, the visual view avoids the work of building an integration. Reusable API records fit a task that needs repeated comparisons or a separate visualization, within the subscription’s coverage and request limits.
Questions people ask about Dropstab token unlocks
Can I claim tokens through Dropstab’s unlock tracker?
Dropstab’s unlock tracker doesn’t distribute or custody the tokens that appear in its schedules. An entry describes release information for a tracked asset. It doesn’t establish that you own an allocation or qualify for a distribution. Claim eligibility follows the relevant token’s distribution rules.
Does a token generation event make all allocations tradable?
A token generation event, or TGE, doesn’t automatically make every allocation tradable. An allocation can remain subject to a cliff or later release conditions. Its own schedule determines which part is available at TGE and which part follows a later timetable.
Which API setting selects upcoming unlocks?
The per-token unlock request supports unlocksTimelineFilter with FUTURE and PAST values. FUTURE selects upcoming events, while PAST selects historical entries. The setting changes the requested time scope; a past entry doesn’t confirm that tokens reached an exchange or that a recipient sold them.
How can an unlock API request focus on one allocation?
The per-token unlock endpoint accepts an allocationId parameter for narrowing the request to a particular allocation. The request still identifies the token by its slug. That narrower scope supports questions about one category’s timetable while preserving the separate release rules that other allocations follow.
What does a 404 response mean for a token-unlock request?
A 404 response means that the requested unlock resource wasn’t found. It doesn’t establish that vesting has finished or that the token has no future releases. The per-token request requires the token’s slug, so the requested record and its unlock-data coverage matter when interpreting that response.
How often does the token-unlock API refresh its data?
Dropstab describes token-unlock API updates as real time. That description concerns the data feed; a project’s allocation schedule still governs the planned release. A refreshed record can describe an upcoming event, so data freshness alone doesn’t establish that the release has happened.