How to Verify Launchpad Creator Vesting
A vesting statement is only as specific as its mint, schedule account, beneficiary records, and claim history. LaunchLab vesting is optional and recorded on-chain, with a cliff followed by either linear release or an immediate unlock when the unlock period is zero. Verification requires more than finding a lock percentage in a token page because the total reserved amount, allocated amount, start time, and beneficiary claims answer different questions.
Editorial research by Coinatio, checked against the primary documentation cited below. Educational content only.
- A nonzero total_locked_amount enables vesting, but beneficiary VestingRecords show who can actually claim allocated tokens.
- The vesting clock begins from the program-recorded migration timing, not necessarily the token's creation date or an announced calendar date.
- Claimable amount is cumulative unlocked allocation minus claimed_amount, using native integer arithmetic.
- Vesting does not restrict tokens outside its vault or prove that every team-controlled wallet is covered by the schedule.
Identify the schedule on PoolState
Begin with the mint address and locate the LaunchLab PoolState owned by the canonical program. Confirm base_mint, creator, status, and vesting_schedule. The schedule records total_locked_amount, cliff_period, unlock_period, start_time, and allocated_share_amount. A zero total means LaunchLab vesting is inactive for that pool. Convert token amounts with the mint's decimals only for display and preserve raw u64 values in the verification record.
The total locked amount is a cap reserved by the launch, while allocated_share_amount is the sum assigned to beneficiary records. They need not be equal. An unallocated remainder does not identify a beneficiary and may remain inaccessible under the documented mechanics. Do not label the full reserved amount as a creator allocation unless corresponding VestingRecords support that attribution. Also compare total_locked_amount with mint supply to calculate a percentage using consistent base units.
Resolve beneficiaries and vesting records
Each beneficiary has a VestingRecord PDA derived from the pool and beneficiary address. The record links back to PoolState and stores beneficiary, token_share_amount, and claimed_amount. Verify the account owner and PDA derivation, then sum token_share_amount across all known records. Creator and platform allocations may be created through different instructions, so inspect initialization transactions or use indexed program history to discover records rather than assuming the PoolState creator is the only beneficiary.
The beneficiary key is the signer authorized to claim. If it belongs to a multisig or program, inspect that authority model separately. A label such as team wallet is off-chain metadata and can change. On-chain verification can establish the public key and allocation, but attribution to a person or organization needs additional evidence. One beneficiary generally has one VestingRecord per pool under the documented PDA scheme.
Recompute unlocked and claimable amounts
Before start_time, no amount is unlocked. If unlock_period is zero, the full beneficiary allocation becomes unlocked at start_time. Otherwise, cumulative unlocked tokens equal token_share_amount multiplied by elapsed seconds and divided by unlock_period, capped at the allocation. Integer division truncates, so match on-chain arithmetic rather than rounding a displayed decimal upward. Current claimable amount is cumulative unlocked minus claimed_amount.
Check PoolState status as well as time. Raydium documents claims as available only after migration, and the vesting start is set by the launch lifecycle. Inspect each ClaimVestedToken transaction to confirm the beneficiary signature, source base vault, destination associated token account, gross transferred amount, and updated claimed_amount. For Token-2022 mints with transfer fees, the beneficiary may receive less than the gross amount debited from the vesting source.
- Verify the canonical mint and LaunchLab PoolState first.
- Record schedule fields in seconds and raw token units.
- Derive every known beneficiary PDA and reconcile allocated totals.
- Calculate cumulative unlocked, claimed, and currently claimable amounts separately.
- Inspect claim transactions and destination accounts, not only schedule metadata.
Limits of what vesting proves
LaunchLab vesting covers only tokens assigned to its schedule. It does not lock tokens bought by the creator through the public curve, tokens transferred to related wallets, fee proceeds, Fee Key NFTs, or assets under another vesting program. Holder clustering and funding relationships require separate transaction analysis. A long cliff can also end with an immediate full unlock if unlock_period equals zero, so reporting only the cliff duration can be misleading.
RPC timestamps depend on on-chain clock data, indexers can miss older account-creation transactions, and frontends may cache claimable values. Use finalized account reads, state the observation slot and UTC calculation time, and repeat critical reads through another provider. Report the schedule as a mechanical restriction on identified tokens, not as proof of future conduct or a complete map of creator-controlled supply.
Sources
This article explains technical and market-data concepts. It is not financial, legal, tax, or investment advice. Verify current chain state and primary documentation independently.
