Uncx token vesting for linear and stepped releases

Continuous accrual and scheduled portions

Linear vesting and stepped releases differ in whether additional tokens become available between scheduled unlock dates, even when allocations share an end date. Exponential increases the release rate exponentially over time; Cliff Exponential applies that pattern after an initial cliff.

Linear releases

Linear vesting makes an allocation available continuously and evenly across its release period. Elapsed time determines the vested proportion between the configured start and end. This pattern fits a commitment that accrues throughout the period, with partial access before its completion.

Stepped releases

Stepped vesting holds each later portion until its scheduled unlock. The timing creates gaps between increases in availability, so the interval matters alongside the final date.

Regular intervals

Unlock in Steps releases equal portions at regular intervals. Its configured dates and step count determine the release sequence.

Monthly intervals

Monthly Unlocks releases equal amounts each month over a configured duration. That monthly cadence distinguishes it from a stepped schedule whose interval needs separate consideration.

Cliffs and the first release

A cliff sets a release boundary, while the schedule around that boundary determines whether tokens become available together or progressively. Cliff and Timelock keep the entire allocation unavailable until their configured date, then make it available all at once. A cliff followed by linear or stepped vesting creates a different arrangement: later portions still follow their schedule. Passing a cliff therefore doesn't always make the full allocation claimable.

A final release date can coexist with earlier partial access. Compare the first availability date with the end date whenever an allocation's holding period matters.

Cancellation and recipient rights

Cancellation and transfer settings determine permitted changes after creation, so they belong beside release timing in the allocation decision. The setup can enable recipient cancellation or transfer. These rights concern the particular vesting arrangement; a linear or stepped label doesn't identify which permissions its creator selected.

A transfer permission concerns the vesting entitlement and its recipient. Keep that separate from the amount currently available to claim. Cancellation also requires its own authorization, and a recipient's cancellation setting doesn't establish an equivalent right for the creator.

View image file

Individual allocations can have different schedules and settings. Agreement on a shared end date doesn't establish identical access or permissions for every recipient.

Match the schedule before committing tokens

If no additional tokens should become available between periodic unlocks, a stepped release fits that requirement. Continuous linear accrual would make additional tokens available during those gaps. Keep the creation transaction unsubmitted while comparing the proposed dates and permissions. An end date alone cannot confirm that the selected pattern matches the intended commitment.

View image file

• Choose linear release when token availability should increase throughout the release period.
• Choose stepped release when additional portions should become available only at regular unlocks.
• For a cliff, match the first accessible amount and the releases that follow.
• Match recipient cancellation and transfer permissions to the allocation's agreed terms.
• Keep funding uncommitted if the selected deployment's post-incident operating status remains unresolved.

The checkout summary shows the proposed schedule and fees before creation. For periodic releases, check that each portion becomes available only at its scheduled unlock. Revise any mismatched selection before submitting the creation transaction. After creation, the vesting record identifies the committed allocation and schedule; later changes require the contract's supported permissions.

How do unlocked tokens differ from claimed tokens?

The manual-claim dashboard distinguishes amounts that have unlocked, amounts already claimed, and amounts currently available for the recipient to claim. Unlocking changes eligibility under the schedule. A completed claim transfers eligible tokens from the vesting contract. Viewing an unlock date doesn't establish a completed withdrawal. The transaction history records claims, while the available balance describes remaining access. Claim handling also depends on configuration: Solana has a separately priced auto-claim option.

Network and contract-version limits

Network support identifies an environment for vesting; the exact deployment determines which contract version and controls govern the allocation. Ethereum, BNB Chain, Base, and Arbitrum have supported EVM vesting deployments. Solana uses a separate vesting program. These environments don't establish identical schedule options or permissions. Liquidity-locker availability also doesn't establish vesting support on the same chain.

The 14 October 2026 Smart Token Vesting V2 exploit corrupted the accounting that connected pooled tokens to recorded shares. UNCX Network's Smart Token Vesting V2 Cross-Chain Incident Report, version 2.0 published on 15 October 2026, identifies affected deployments on Ethereum, BNB Chain, Base, and Robinhood. The accounting failure enabled attacker-controlled positions to withdraw more tokens than their operators had supplied.

The report records post-incident asset returns without confirming an outcome for every affected recipient or a recovery timetable. A suitable release curve doesn't establish readiness to fund an affected deployment. Resolve that contract's operating status before making a new commitment.

Allocation costs and the funded amount

Vesting costs can combine a network-specific service charge with a fee on allocated tokens, while network gas remains a separate expense. A token-based fee uses the amount allocated to vesting as its base. A release pattern alone doesn't establish the applicable charge. The quoted service fee therefore needs the same network, contract version, and configuration as the proposed allocation.

Keep the intended recipient allocation distinct from the service charge when preparing the funding balance. Review the fee and schedule together at checkout, without assuming that a published charge applies unchanged to every deployment. Set the funded amount after reconciling the applicable costs with the token allocation that the recipient should receive.