Claiming Tokens & Vesting

After a Liquidity Generation Event (LGE) completes successfully, the tokens a user bought during the sale become claimable. The LGE creator chooses, at creation time, one of two release models for the whole campaign — immediate claim or governance-managed vesting — and that choice applies identically to the creator and to every contributor. This page describes the mechanics of both paths, where the state lives, and how vested tokens are managed afterwards.

The creator’s choice: immediate vs vesting

When the LGE is created, the creator picks whether tokens are immediately claimable or subject to a vesting schedule. The decision applies to both the creator and contributors — there is no per-user override. The LGE detail page surfaces whether vesting is enabled before a user participates, so contributors know the release model up front.

Model	What the user receives at claim	Where tokens end up	Who manages it afterwards
Immediate claim	Full balance, minus a `0.01` token fee, transferred at claim	The user’s wallet	The user (tokens are liquid)
Vesting (delayed unlock)	Tokens transferred and locked on a release schedule	Locked (OhShii Locker) until each unlock fires	The user + the campaign’s governance canister

Immediate claim

If vesting is disabled, tokens are claimable immediately after purchase. On claim the tokens are transferred directly to the user’s wallet, minus a 0.01 token fee. Once claimed, the tokens are fully liquid — there is no lock, no schedule, and nothing further to activate.

Vesting (governance-managed delayed unlock)

If vesting is enabled, vesting locks are created in a FROZEN (inactive) state at LGE completion. During finalization the backend calls the campaign’s governance canister (sons_governance) batch_create_vesting_locks and sets governance_vesting_enabled — this step is idempotent and re-runs cleanly on a Frozen-state finalization retry. No unlock timer starts until the user activates.

Each vesting lock holds its tokens in a dedicated custody subaccount of the governance canister — one per lock, kept separate from the DAO treasury account. Each scheduled unlock transfers out of that lock’s own subaccount to its beneficiary. This is invisible from the user’s side (you still just activate and receive tranches on schedule); it only defines where the tokens are held while locked.

Activation within one week

Users must click the “CLAIM TOKENS” / “ACTIVATE VESTING” button within one week of LGE completion to start their vesting schedule. Activation is a frontend-driven call to governance activate_vesting, followed by dao_storage.confirm_vesting_activation. Until activation happens, the locks stay frozen and no tokens are released.

Who vesting applies to

The creator decides, at LGE creation, the scope of vesting: only the creator, only contributors, or both. The same rules apply to whoever is in scope — creator tokens are subject to vesting under the same rules as everyone else when the creator is included.

Unlock schedule and the first-unlock delay

The creator configures the vesting frequency:

Frequency	Max unlocks	Approx. total duration
Weekly	up to 104	~2 years
Monthly	up to 24	~2 years

The first unlock comes one full schedule period after activation (only high-allocation creators wait longer):

All users (including creators) use a 1x base delay — the first unlock is one full frequency period after activation (e.g. for a weekly schedule, 1 week after activation).
Extra delay for high-allocation creators: if the creator purchased more than 12 million tokens total during the LGE, their first unlock is delayed to 3x the frequency period — e.g. weekly = 3 weeks after activation. This applies only to the creator’s own locks and exists to make distribution fairer and build participant confidence.

Unlock timestamps are calculated at activation, and unlocks are executed automatically based on the blockchain timestamp.

Where vested tokens live and how they are managed

SONS vesting locks are not ordinary OhShii Locker locks. They live in the campaign’s own sons_governance canister, and the launcher backend cannot modify them once created — only the user (via governance methods) and the governance canister itself can. ONS proposals do not apply to these locks. Users track vesting progress and the schedule through the launcher/locker UI, with unlocks processed by the governance timer.

The same sons_governance canister also hosts manual “additional” locks — locks a user creates for that DAO’s token via create_additional_lock (from either the launcher or the OhShii Locker frontend). Those are not part of the claim flow (the user is locking their own tokens, not receiving a vested allocation), but they share the same home and custody model. See OhShii Locker integration for the full picture.

Aspect	SONS vesting (LGE)
State lives in	The campaign’s `sons_governance` canister
Created by	Launcher backend at finalization (`batch_create_vesting_locks`)
Activated by	The user, via the launcher frontend (`activate_vesting` + `confirm_vesting_activation`)
Unlocks processed by	The `sons_governance` timer
Launcher backend can modify?	No — only the user and the governance canister

For the delayed-unlock claim path that routes tokens through the OhShii Locker canisters (list-token-if-needed, prepare_lock_on_behalf_of, transfer to the locker strongbox, finalize_lock_on_behalf_of), see OhShii Locker integration. For the broader finalization sequence that creates the vesting locks, transfers the liquidity position, and seals DAO autonomy, see the full flow in Core Workflows.