In this guide
A cliff label is only part of the schedule
A token vesting schedule describes when allocated units become vested under stated conditions. In the documentation examples discussed here, a cliff is an initial boundary before which no units become available under the specified rule. The word alone does not tell you whether the full allocation becomes claimable at that boundary or whether a stepped schedule catches up and continues.
Read the allocation, start, cliff rule and later steps together. Then separate three questions: how much is cumulatively vested, how much was added during a particular interval, and what has actually been claimed or received. They are not the same quantity.
Check what the named cliff actually does
Sui’s Token Vesting Strategies documentation gives a standalone cliff example in which nothing is claimable before the cliff boundary and the full remaining allocation becomes claimable at it. Becoming claimable in that example is distinct from a completed claim or a transfer into a recipient’s wallet.
OpenZeppelin’s contracts-sui finance README describes a different arrangement: an optional cliff on an underlying stepped schedule. The gate keeps the cumulative vested amount at zero before the cliff. At the boundary, the schedule can catch up to the steps already elapsed, then continue on its original cadence. The cliff gates the staircase; it does not move the staircase’s start.
| Named example | Before the boundary | At the boundary and later | Reading limit |
|---|---|---|---|
| Sui standalone cliff | Nothing is claimable under this example | The full remaining allocation becomes claimable at the boundary | Claimable does not mean already received |
| OpenZeppelin optional cliff on steps | Cumulative vested units remain zero before the gate | Catch up to elapsed steps, then continue the original cadence | The gate does not shift the schedule’s start |
These are two named documentation examples, not a rule for every token or contract. The Sui page is undated, and the OpenZeppelin explanation was read from an undated README on its main branch, without a pinned release or commit. Neither example verifies the behavior of a particular deployed contract.
Declare the allocation, start and gate
For an original fictional example, assume a fixed allocation of 1,200 invented token units. The underlying schedule has twelve equal steps of 100 units, one at each period boundary from 1 through 12, measured from start 0. A cliff gate at time 3 holds the cumulative vested amount at zero beforehand. At time 3, it catches up to 300; later steps keep their original times.
Here, t means elapsed illustrative periods, not calendar months or a blockchain timestamp. V(t) means the cumulative units vested under this declared schedule. Each snapshot is taken after the boundary at its stated time.
- Before time 3, V(t) = 0.
- From time 3 until just before time 12, V(t) is 100 times the number of whole periods completed.
- At time 12 and afterward, V(t) = 1,200.
The allocation stays fixed. We model no topups, revocations, claims, releases, transfers or fees. The numbers do not come from a token project or either documentation example, and they are not the result of running contract code.
Separate the cumulative total from the interval addition
The second column below is a snapshot: everything cumulatively vested under our rule by that time. The last column is a change: the units added since the previous row’s time. The interval notation (a,b] means after a through and including b.
| As-of time t | Cumulative V(t), units | Interval since prior row | Interval width | Newly scheduled units: V(b) − V(a) |
|---|---|---|---|---|
| 0 | 0 | Start | — | — |
| 2 | 0 | (0,2] | 2 periods | 0 |
| 3 | 300 | (2,3] | 1 period | 300 |
| 4 | 400 | (3,4] | 1 period | 100 |
| 12 | 1,200 | (4,12] | 8 periods | 800 |
At time 3, the gate opens and V(3) = 3 × 100 = 300. At time 4, V(4) = 4 × 100 = 400. The addition between those two snapshots is 400 − 300 = 100 units.
From time 4 through time 12, the addition is V(12) − V(4) = 1,200 − 400 = 800 units over eight periods. That 800 is not a one-period rate. The cumulative total at time 12 is still 1,200 units, rather than 800.
The interval additions reconcile to the allocation: 0 + 300 + 100 + 800 = 1,200. Adding the cumulative column instead would count some of the same units repeatedly. None of these columns records a claim, a wallet receipt or a sale.
Scheduled, claimable and received are different states
The named examples keep track of more than a schedule. Sui’s linear illustration accounts for prior claims when determining the amount available to claim at a given time. OpenZeppelin’s description likewise separates the cumulative vested amount from units already released and the portion not yet released.
Our timeline calculates only its declared cumulative amount and interval differences. It does not calculate what is actually claimable or releasable, what has been claimed or released, or what a wallet has received. It also establishes no transferability, legal entitlement or circulating-supply classification. The separate guide to product rights and obligations addresses a different question from reading a schedule.
A scheduled quantity is not completed cash movement. For the distinction between a displayed position value and a completed exit in prediction markets, see the guide to managing and selling a position. That trading example is separate from this fictional token allocation.
A vesting label also supplies no forecast of selling or price, and no guarantee against dumps or rug pulls. This illustration is not a security assessment. Whether a quantity could be traded at a particular price is another question; the order-book and AMM guide explains the separate offers or pool state behind a quote.
Common questions about vesting cliffs
Does every cliff release the full allocation at once?
The label does not establish that. Sui’s standalone example makes the full remaining allocation claimable at its boundary. OpenZeppelin’s optional cliff on steps can instead catch up to elapsed periods and continue. Check the declared rule rather than treating these examples as one universal definition.
Does a cliff always move the start of the schedule?
Not in OpenZeppelin’s named stepped example: its gate does not shift the underlying start. Our fictional schedule follows that declared shape, so time 3 catches up to 300 units. That is a condition of this example, not an assumption to apply to every cliff.
Why are 1,200 units vested at time 12 but only 800 added since time 4?
The first number is the cumulative total at time 12. The second subtracts the 400 already vested at time 4: 1,200 − 400 = 800. The interval spans eight illustrative periods, not one, and neither number is a recorded receipt.
Are vested tokens already claimed or in my wallet?
You cannot infer that from the timeline. The named documentation distinguishes cumulative vested units from claims or releases. Our table models no such transaction and establishes neither an actual claimable balance nor a transfer, receipt or entitlement.
Does a vesting schedule prevent selling or protect the price?
No such guarantee follows from this lesson. The fictional schedule models no selling, market price or cash value. A vesting label alone is not evidence of price protection, contract security, personal eligibility or protection from a rug pull.
Explore HypaForecast markets
Browse market questions and the current BTC round details. These links are separate from the fictional allocation and do not establish token issuance, vesting, claim features, current availability or eligibility.
Sources and scope
- Sui Documentation: Token Vesting Strategies — undated documentation examples, including the standalone cliff and separate linear-claim accounting.
- OpenZeppelin: contracts-sui finance README — undated text read from the main branch, describing an optional cliff on a stepped schedule and separate vested/released accounting.
These explanatory texts were checked on 19 October 2026, which is not their publication date. They are documentation examples, not verification of a deployed contract or a security audit. The 1,200-unit timeline is original fictional arithmetic, with no calendar-month, claim, transfer, token-price or real-project data.
HypaForecast publishes educational guides and operates a prediction market. This schedule explanation does not establish that HypaForecast issues a token, offers vesting or token-claim features, or that you are eligible to trade.
Share this guide