2.2.4. Unlock Schedules

2-6-1. Unlock Schedule <> Reserve Schedule

---

Unlock Schedules, so called Circulating Supply Schedules, are intrinsically interchangeable with project’s reserve schedule, which are deem to be more practical for circulating supply verification since Reserve Schedules of each $AllocationCategory$ is directly comparable to sum of $NonCirculatingSupply$ designated to each $AllocationCategory$.

Therefore, by looking into the following equation we can derive two simple idea on how to get a reserve schedule from a project’s reserve schedule.

$$\sum_{i=1}AC_{nc}$$

• Transition from unlock schedules to reserve schedules require $AC(t_{TGE})$ if the schedule given by the project doesn’t cover the whole distribution timespan.

• Can Unlock Schedules be used without having to pass $AllocationCategories$ verification?

2-6-2. Unlock Schedule Changes

---

This Section aims to solve various modifications in unlock schedules - Questions include the following:

• What happens if an Unlock Schedule changes in the middle of its emission schedule?

• What happens if from certain day $t$, an allocation category of amount $Q$ is then designated to a different allocation category?

• What happens if the change in allocation category changes happen multiple times ?

  • A project’s wallet cannot have multiple Allocation Categories in its lifetime but only once per single $t$

• Can a project's Unlock Schedules be transferred into Project's Retention Schedule?

2-6-3. Allocation Categories Logic

---

Project label their token reserves via different usage purposes, in the form of $AllocationCategory$, $AC_{i}(t)$ where $i=1,2, ... i..., n$ with respective to time variant $t$, which is again an arbitrary, scheduled label on its fungible tokenomics.

In the context of tracking supply data, Below characteristics must be taken into account:

• Each $AllocationCategory$, $AC_{i}$ consists of a non-circulating part $AC_{i_{nc}}$ and a circulating part $AC_{i_{c}}$ which satisfies below equation.

  $$AC_{i}(t) = AC_{i_{nc}}(t) + AC_{i_{c}}(t)$$
• The operating entity may change its allocation status multiple times in order to rebalance its resource distribution, which will be done to ultimate serve the project’s higher mission objectives.

  • Changes in allocation categories can only occur in $AC_{i_{nc}}(t)$ as it will be clearly impossible for the operating entity to control $AC_{i_{nc}}(t)$, which are already in circulation.

  • Changes will occur in a way that source allocation category $AC_{source_{nc}}(t)$ transfers tokens of amount $Q$ to destination allocation category $AC_{destination_{nc}}(t)$, which satisfies below two equations with respective to time $t$ and $t+1$:

    $$AC_{source}(t+1) = AC_{source_{c}}(t) + AC_{source_{nc}}(t) -Q$$

    $$AC_{destination}(t+1) = AC_{destination_{c}}(t) + AC_{destination_{nc}}(t) +Q$$