Déblocage progressif dans LaunchLab

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

​

Pourquoi le déblocage progressif

• Allocation d’équipe. Un créateur réserve, par exemple, 5 % de la réserve pour l’équipe fondatrice, bloquée pendant 6 mois et débloquée linéairement sur les 12 mois suivants.
• Allocation de plateforme. Une plateforme de lancement reçoit une tranche de chaque jeton qu’elle liste, selon le même calendrier, via CreatePlatformVestingAccount.
• Allocations aux conseillers / contributeurs. Plusieurs bénéficiaires avec leurs propres comptes VestingRecord, chacun suivant indépendamment son montant réclamé.

​

Forme du calendrier

// states/pool.rs
pub struct VestingSchedule {
    pub total_locked_amount:     u64,
    pub cliff_period:            u64,
    pub unlock_period:           u64,
    pub start_time:              u64,   // set by the program at fundraising end
    pub allocated_share_amount:  u64,   // running sum of allocations to vesting records
}

​

Formule de déblocage linéaire

elapsed         = min(now, start_time + unlock_period) − start_time
unlocked_amount = token_share_amount × elapsed / unlock_period

delta_amount    = unlocked_amount − vesting_record.claimed_amount
vesting_record.claimed_amount = unlocked_amount

​

Dispositions des comptes

​

VestingSchedule

​

VestingRecord

seeds = [
  b"pool_vesting",
  pool_state.key(),
  beneficiary.key(),
]
program = LaunchLab program

// states/vesting.rs
#[account]
pub struct VestingRecord {
    pub epoch:               u64,         // recent_epoch tracker
    pub pool:                Pubkey,      // back-pointer to PoolState
    pub beneficiary:         Pubkey,      // who can call ClaimVestedToken
    pub claimed_amount:      u64,         // cumulative claimed
    pub token_share_amount:  u64,         // total allocated to this beneficiary
    pub padding:             [u64; 8],
}

​

Instructions

​

CreateVestingAccount

share_amount: u64    // tokens to assign to this beneficiary

• share_amount > 0.
• pool_state.vesting_schedule.allocated_share_amount + share_amount <= total_locked_amount.
• La clé publique du beneficiary n’a pas de VestingRecord existant pour ce pool.

• vesting_record initialisé avec token_share_amount = share_amount, claimed_amount = 0.
• pool_state.vesting_schedule.allocated_share_amount += share_amount.

​

CreatePlatformVestingAccount

​

ClaimVestedToken

• block_time >= pool_state.vesting_schedule.start_time (sinon VestingNotStarted).
• pool_state.status == PoolStatus::Migrated — la graduation doit avoir déjà eu lieu. L’appel avant la graduation revient.
• Le delta du montant débloqué est supérieur à zéro. Un appel sans opération (delta calculé est 0) revient.

• vesting_record.claimed_amount avance vers le nouveau montant cumulatif débloqué.
• delta_amount de jeton de base est transféré vers beneficiary_ata.

​

Exemple détaillé

• supply = 1_000_000_000
• total_locked_amount = 100_000_000 (10 % de la réserve)
• cliff_period = 180 * 86400 (180 jours)
• unlock_period = 365 * 86400 (1 an linéaire après la période d’indisponibilité)

• Bénéficiaire A (équipe) : share_amount = 70_000_000
• Bénéficiaire B (conseiller) : share_amount = 30_000_000

elapsed         = min(now, start_time + 365·86400) − start_time
                = 90 · 86400
unlocked_amount = 70_000_000 × (90 / 365) ≈ 17_260_274
delta_amount    = 17_260_274 − 0 = 17_260_274

unlocked_amount = 70_000_000 × (270 / 365) ≈ 51_780_822
delta_amount    = 51_780_822 − 17_260_274 = 34_520_548

​

Cas limites

• Bénéficiaire perd sa clé. La clé publique sur VestingRecord.beneficiary est le seul signataire pouvant appeler ClaimVestedToken. Il n’y a pas de chemin de récupération. Définissez le bénéficiaire sur un multisig si la récupération est importante.
• Frais de transfert Token-2022. Si le mint de base est un mint Token-2022 avec une extension de frais de transfert, le bénéficiaire reçoit delta_amount − transfer_fee, pas le delta complet. Le coffre-fort du pool enregistre toujours le montant brut comme transféré — la différence s’accumule sur le compte de frais retenus du mint.
• Pool non gradué. L’appel de ClaimVestedToken avant la graduation revient. L’horloge de déblocage progressif commence uniquement lorsque la levée de fonds se termine réellement ; un lancement avorté (qui ne définit jamais start_time) laisse les jetons bloqués inaccessibles dans le coffre-fort.
• Tentatives de surallocation. Le programme applique allocated_share_amount <= total_locked_amount à chaque CreateVestingAccount. Le reste (s’il y en a) de total_locked_amount laissé non alloué est perdu — ces jetons restent dans le coffre-fort pour toujours une fois que le lancement se termine. Allouez le montant complet sauf si c’est l’intention.

​

Références

• products/launchlab/accounts — disposition complète de PoolState incluant VestingSchedule.
• products/launchlab/instructions — cycle de vie de la graduation.
• products/launchlab/platform-config — sémantique de platform_vesting_scale pour les allocations de plateforme.
• products/launchlab/global-config — plafond de max_lock_rate qui limite total_locked_amount.

• raydium-launch/programs/launchpad/src/states/vesting.rs — VestingRecord.
• raydium-launch/programs/launchpad/src/states/pool.rs — VestingSchedule, VestingParams, is_vesting_started, vesting_end_time.
• raydium-launch/programs/launchpad/src/instructions/create_vesting_account.rs.
• raydium-launch/programs/launchpad/src/instructions/claim_vested_token.rs.