Claiming Tokens & Vesting

After a Liquidity Generation Event (LGE) completes successfully, the tokens a user bought during the sale become claimable. A campaign uses one of two release models — immediate claim or governance-managed vesting — applied identically to the creator and to every contributor. Every LGE created today uses vesting: the backend refuses (VESTING_REQUIRED) a new campaign whose vesting does not apply to both the creator and contributors. Immediate claim remains only on campaigns created before vesting became mandatory. This page describes the mechanics of both paths, where the state lives, and how vested tokens are managed afterwards.

Release model: immediate vs vesting

The release model is fixed per campaign at creation. It 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 in the campaign’s own governance canister (`sons_governance`) until each unlock fires	The user + the campaign’s governance canister

Immediate claim

On a campaign without vesting, 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.

A claim whose earlier attempt is older than the retry window. Each claim fixes one ledger timestamp (created_at_time) per campaign and wallet, and every retry reuses it. So when the reply of an attempt is lost, a retry is deduplicated by the token ledger instead of paying a second time. The ledger deduplicates only within its window (about 24 hours), so once the first attempt is more than 23 hours old the backend stops retrying: it refuses every further claim for those contributions, because it can no longer tell a delivered transfer from one that never landed. If the earlier attempt did deliver the tokens, they are already in the wallet, and the token ledger’s balance and history show the transfer; the contributions are still recorded as unclaimed, so the campaign page can keep showing them as claimable while each claim is refused. The refusal is what prevents a double payment. Clearing an attempt that never landed goes through admin_clear_claim_cat, which accepts an approved ONS proposal (a custom call to the backend) or the ONS guardian (during the pre-DAO bootstrap phase, also the backend’s bootstrap authorized callers).

Vesting (governance-managed delayed unlock)

On a vesting campaign, 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

Vesting applies to both the creator and every contributor; the backend refuses a new campaign that scopes it to only one of them. Creator tokens are subject to vesting under the same rules as everyone else, with the one extra delay described below.

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.

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

There is no claim path that routes vesting tokens through the OhShii Locker: for every campaign the vesting locks are created in the campaign’s sons_governance canister, and a claim on a vesting campaign creates no lock and calls no Locker canister. Where each kind of lock lives is summarised in 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.