---
title: "Vesting des jetons"
description: "Le vesting rend une allocation disponible selon un calendrier. Découvrez le cliff et la libération linéaire, les preuves on-chain à vérifier et pourquoi des jetons acquis ne sont pas nécessairement vendus."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Vesting des jetons

> À des fins éducatives uniquement ; ne constitue pas un conseil en investissement. Tout investissement peut entraîner des pertes.

<a id="answer"></a>

## Réponse directe

Le vesting des jetons est une règle qui rend l'allocation d'un bénéficiaire disponible selon un calendrier plutôt qu'en une seule fois. Un **cliff** est la période précédant la première acquisition ; ensuite, les jetons peuvent être acquis en continu, par tranches ou à des jalons.

Le vesting ne signifie pas à lui seul émission ou vente. Les jetons peuvent déjà exister tout en étant bloqués, ou être créés lors de la libération. Un montant acquis peut rester non réclamé, non transférable selon une autre règle, conservé par le bénéficiaire ou vendu plus tard.

L'analyse doit distinguer cinq événements : **alloué, acquis, réclamé, transférable et vendu**. Seul le dernier est une vente réelle, dont l'effet dépend des anticipations, du comportement des détenteurs et de la liquidité exécutable.

<a id="mechanism"></a>

## Fonctionnement

1. **Lire les conditions juridiques et publiées.** Identifier allocation, bénéficiaire, début, cliff, fin, fréquence, jalons, droits de révocation et pouvoir de modification.
2. **Vérifier l'implémentation.** Contrôler adresse du jeton, contrat de vesting, bénéficiaire, horodatages, montant libéré, réclamations, pouvoirs de proxy ou d'administrateur et code source vérifié. Le `VestingWallet` d'OpenZeppelin est une implémentation, pas une norme universelle.
3. **Rapprocher les catégories d'offre.** Déterminer si les jetons bloqués figurent dans l'offre totale et si le déblocage change l'offre en circulation sans changer l'offre totale. ERC-20 définit les transferts, mais ni « offre en circulation » ni calendrier de vesting.
4. **Tracer le chemin vers le marché.** Les jetons acquis ne deviennent une offre potentielle que s'ils sont réclamables et transférables. Un dépôt sur une plateforme, un bridge, un pool ou un nouveau portefeuille prouve un mouvement, pas une vente.
5. **Comparer scénarios et liquidité.** Estimer la fraction vendable et la comparer à la profondeur du carnet ou aux réserves AMM. Distinguer profondeur et volume ; le volume passé ne garantit pas un acheteur.

Pour une allocation `A`, une libération au cliff `C`, une date de cliff `T_c` et une date finale `T_e`, une règle linéaire possible est :

`vested(t) = 0` avant `T_c` ; sinon `C + (A - C) × min((t - T_c) / (T_e - T_c), 1)`

Les contrats réels peuvent appliquer d'autres arrondis, horodatages, révocations ou jalons. Les documents contraignants et le code du contrat prévalent.

<a id="example"></a>

## Exemple chiffré

Un contributeur reçoit 12,000,000 jetons. Rien n'est acquis pendant un cliff de 12 mois. Au mois 12, 3,000,000 sont acquis ; les 9,000,000 restants le sont sur les 24 mois suivants, soit 375,000 par mois.

Au mois 18, six tranches mensuelles post-cliff sont acquises : `3,000,000 + 6 × 375,000 = 5,250,000` jetons cumulés. Si 2,000,000 ont été réclamés, 3,250,000 sont acquis mais non réclamés. Ce calcul ne dit pas combien ont été transférés ou vendus.

Si 100,000,000 jetons circulent et que la tranche du mois 12 devient transférable, elle représente 3% de l'offre en circulation. Si le bénéficiaire en vend 20%, la vente envisagée est de 600,000 jetons, pas 3,000,000. L'impact doit être testé face à la liquidité exécutable actuelle.

<a id="risks"></a>

## Risques et vérifications

- **Calendrier incomplet ou modifiable.** Avenants, jalons, clés d'administration, gouvernance ou mises à niveau peuvent le changer. Noter qui peut modifier chaque condition.
- **Risque de contrat et de garde.** Bugs, clés compromises, mauvais bénéficiaire, migration ou échec de réclamation peuvent retarder ou détourner les libérations. Vérifier adresses et transactions finalisées.
- **Mauvaise classification de l'offre.** Les fournisseurs traitent différemment trésorerie, jetons bloqués, bridgés, brûlés ou non réclamés. Rapprocher les définitions avant tout pourcentage.
- **Risque de liquidité et de concentration.** Une grosse tranche détenue par quelques bénéficiaires à faible coût peut dépasser des achats minces ; le déblocage ne prouve toutefois pas une vente.
- **Fausse précision.** Le calendrier peut utiliser temps de bloc, secondes, périodes discrètes, arrondis ou réclamation manuelle. Lire l'état réel du contrat près de l'événement.

<a id="misconceptions"></a>

## Idées reçues

### « Acquis » signifie « vendu »

Non. Le vesting établit un droit. Réclamer, transférer, déposer et vendre sont des actes distincts exigeant des preuves distinctes.

### Un cliff libère toute l'allocation

Pas nécessairement. Il fixe seulement le premier moment d'acquisition ; première tranche et courbe suivante dépendent du calendrier.

### Un déblocage augmente toujours l'offre totale

Non. Des jetons déjà créés peuvent devenir transférables sans la changer. Une création à la libération peut l'augmenter ; vérifier contrat et comptabilité.

### Un gros déblocage garantit une baisse du prix

Non. Anticipations, demande, couverture, comportement et liquidité comptent aussi. Fraction vendable et impact sont des scénarios, pas des certitudes.

<a id="related"></a>

## Sujets connexes

- [Offre en circulation](/fr/crypto/circulating-supply/)
- [Émission de jetons](/fr/crypto/token-emission/)
- [Déblocage de jetons](/fr/crypto/token-unlock/)
- [Analyser les cliffs de vesting et la liquidité](/fr/crypto/token-vesting-cliff-liquidity/)
- [Tokenomics](/fr/crypto/tokenomics/)

<a id="sources"></a>

## Sources

- [VestingWallet](https://docs.openzeppelin.com/contracts/5.x/api/finance#VestingWallet) - OpenZeppelin (consulté le 2026-08-22)
- [ERC-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté le 2026-08-22)
- [Pricing](https://docs.uniswap.org/contracts/v2/concepts/advanced-topics/pricing) - Uniswap (consulté le 2026-08-22)

Source: https://wiki.fcontext.com/fr/crypto/vesting/index.mdx