
Le locktime correspond à une période de maturité prédéfinie pour des fonds ou des opérations sur une blockchain. Avant le moment ou l’événement spécifié, il est impossible de dépenser les fonds ou d’exécuter l’opération concernée. Une fois le locktime expiré, les actifs ou actions deviennent disponibles. Le locktime peut être déterminé par un instant absolu (date/heure ou hauteur de bloc) ou par un intervalle relatif à compter d’une certaine confirmation.
On distingue deux formes principales de locktime : absolu et relatif. Le locktime absolu fonctionne comme un dépôt à terme, en précisant l’instant ou la hauteur de bloc exacts à partir desquels les fonds deviennent accessibles. Le locktime relatif agit comme une période de refroidissement, imposant qu’un nombre de blocs ou une période définie s’écoule après la confirmation d’une transaction avant de pouvoir utiliser les actifs.
Ce mécanisme est largement utilisé pour différer le règlement des transactions, la distribution différée de tokens pour les équipes, le verrouillage lors du staking et du yield farming, l’exécution différée de la gouvernance, ainsi que pour les atomic swaps inter-chaînes et les garanties de paiement dans le Lightning Network.
Sur Bitcoin, le locktime peut être appliqué aussi bien au niveau de la transaction qu’au niveau du script. Au niveau transactionnel, le champ nLockTime détermine le moment le plus précoce où une transaction peut être confirmée. Au niveau du script, des opcodes spécifiques valident les conditions de verrouillage lors de la dépense des fonds.
Implémentation au niveau transactionnel :
Le champ nLockTime prend en charge deux bases : si la valeur est inférieure à environ 500 millions, elle est interprétée comme une hauteur de bloc ; si elle est supérieure ou égale, elle est lue comme un timestamp Unix. Pour que nLockTime soit effectif, chaque numéro de séquence d’entrée ne doit pas être réglé à sa valeur maximale ; sinon, la transaction est considérée comme immédiatement dépensable.
Implémentation au niveau script :
OP_CHECKLOCKTIMEVERIFY (CLTV, introduit via BIP-65 en 2015) permet aux scripts d’imposer que les fonds ne soient dépensés que si la hauteur de bloc ou le timestamp atteint un seuil défini.OP_CHECKSEQUENCEVERIFY (CSV, introduit via BIP-68/112 en 2016) prend en charge le locktime relatif en imposant un intervalle spécifique (en blocs ou en temps) après la confirmation de la transaction avant d’autoriser la dépense.Par exemple, il est possible de créer une transaction à destination de votre « vous du futur » qui ne pourra être dépensée qu’après le bloc 900 000, ou d’exiger via CSV que les fonds soient verrouillés pendant 100 blocs supplémentaires après confirmation. Bitcoin utilise également la « median time past » des 11 derniers blocs (BIP-113) afin de limiter la capacité des mineurs à manipuler les timestamps.
Sur des plateformes comme Ethereum, le locktime est généralement implémenté via des variables de smart contract et des contrôles d’accès. Avant expiration, les retraits, modifications de paramètres ou distributions de tokens sont rejetés par le contrat ; après l’échéance, ces actions deviennent possibles.
Trois applications courantes incluent :
Les développeurs utilisent fréquemment des bibliothèques auditées (par exemple, TimelockController et contrats Vesting d’OpenZeppelin) pour configurer les délais minimums, les permissions de rôle et les bénéficiaires, renforçant ainsi la sécurité.
Dans le yield farming DeFi ou les produits de staking sur exchanges centralisés, le locktime détermine la liquidité et le rendement annualisé. Des périodes de verrouillage plus longues offrent généralement des rendements plus élevés, mais limitent la possibilité de réallouer les fonds pendant la période de blocage.
Sur des plateformes comme Gate, vous trouverez des options telles que « flexible », « 7 jours », « 30 jours » ou « 90 jours » pour le locktime. Les produits flexibles proposent des rendements plus faibles mais autorisent le retrait à tout moment ; les options à terme fixe rémunèrent davantage mais peuvent entraîner des frais de sortie anticipée ou la perte des récompenses. Il convient de vérifier si le rachat anticipé est autorisé, comment les rendements sont calculés et si le rachat automatique à maturité est proposé lors du choix d’un produit.
Une stratégie efficace consiste à échelonner les périodes de verrouillage (« laddered locking ») en répartissant les fonds sur plusieurs durées pour équilibrer liquidité et rendement. Il est recommandé de conserver une part de fonds flexibles pour les besoins de court terme afin d’éviter des ventes forcées à des prix défavorables.
Les swaps inter-chaînes et le Lightning Network utilisent des Hash Time-Locked Contracts (HTLC) pour garantir l’atomicité : soit l’échange aboutit pour les deux parties, soit les deux sont remboursées. Le « hash lock » garantit que seuls ceux disposant du secret correct peuvent réclamer les fonds ; le « time lock » assure qu’en cas d’expiration, les fonds sont restitués à leur propriétaire initial.
Le processus fonctionne ainsi : la partie A verrouille des fonds on-chain afin que la partie B ne puisse les réclamer qu’avec le bon « mot de passe » avant l’échéance ; sinon, la partie A peut se rembourser après expiration. La partie B effectue l’opération miroir sur une autre chaîne, permettant ainsi que les deux réussissent ou que les deux expirent et soient annulées.
Dans le Lightning Network, les canaux de paiement utilisent des locktime relatifs pour sécuriser les fonds en cas d’échec de paiement. Les délais sont adaptés en fonction des temps de confirmation du réseau et de la congestion : les swaps on-chain utilisent généralement des timeouts compris entre plusieurs heures et une journée pour permettre les confirmations et les actions des utilisateurs.
Les deux méthodes définissent le moment où les fonds deviennent disponibles, mais chacune présente ses avantages et inconvénients. La hauteur de bloc mesure le nombre de blocs restants à miner, ce qui évite la dérive de l’horloge ; les timestamps sont plus intuitifs mais peuvent être ajustés par les mineurs ou validateurs.
Sur Bitcoin, les valeurs nLockTime inférieures à ~500 millions sont interprétées comme des hauteurs de bloc (idéal pour « attendre N blocs »), tandis que les valeurs plus élevées sont des timestamps Unix (adaptés à des dates calendaires précises). Sur Ethereum, les contrats utilisent généralement block.timestamp, mais les temps réels de bloc peuvent varier de plusieurs dizaines de secondes selon les conditions réseau : les timelocks prévoient donc souvent des marges suffisantes pour garantir la robustesse.
Bonnes pratiques : Utiliser la hauteur de bloc pour les jalons techniques (par exemple, exécuter après N blocs post-upgrade) ; utiliser les timestamps pour les engagements externes (par exemple, déverrouiller à une date UTC précise), en prévoyant toujours une marge de sécurité.
Les principaux risques concernent la contrainte de liquidité, la volatilité des prix et les aspects d’implémentation. Plus la période de verrouillage est longue, plus le risque de manquer des opportunités de marché augmente ; un besoin urgent avant l’échéance peut forcer un rachat anticipé avec perte de rendement ou pénalités.
Sur le plan technique, les timestamps peuvent être ajustés par les mineurs/validateurs. Bitcoin limite cela via la règle « median time past » (pas avant la médiane des 11 derniers blocs), et la plupart des réseaux plafonnent la dérive horaire autorisée (par exemple, jusqu’à deux heures). Sur Ethereum, une manipulation mineure du timestamp reste possible : il est donc déconseillé de s’appuyer sur une précision à la seconde.
Les erreurs de configuration sont également courantes : confusion entre seuils (blocs vs secondes), oubli de régler les séquences d’entrée pour nLockTime, ou permissions de timelock incorrectes pouvant rendre les actifs inaccessibles. Si les actifs verrouillés servent de collatéral, une baisse de prix pendant la période de lock peut entraîner une liquidation sans possibilité de renflouer rapidement.
Pour les développeurs et utilisateurs, la démarche sécurisée repose sur le triptyque « concevoir-configurer-vérifier » :
Étape 1 (développeurs Bitcoin) : Choisir entre locktime absolu ou relatif. Pour l’absolu avec nLockTime, régler toutes les séquences d’entrée sous la valeur maximale ; pour le relatif, utiliser CSV avec un encodage bloc/temps correct. Toujours tester sur testnet avant déploiement.
Étape 2 (développeurs Ethereum) : Utiliser des contrats Timelock et Vesting audités ; configurer les délais minimums, les rôles et les procédures d’urgence. Pour l’exécution de la gouvernance, suivre le processus proposition → file d’attente → délai → exécution, et rejouer les scénarios clés en environnement de test.
Étape 3 (utilisateurs quotidiens sur Gate) : Lors du staking ou de l’utilisation de produits de rendement (staking), choisir la période de verrouillage adéquate ; vérifier les règles de rachat anticipé et les éventuelles pénalités ; conserver des fonds flexibles pour les urgences ; programmer des rappels de maturité et surveiller les mises à jour des produits.
Étape 4 (opérations cross-chain & canaux) : Choisir des timeouts HTLC suffisamment longs en tenant compte des confirmations cross-chain et de la congestion réseau ; privilégier les implémentations auditées ; commencer avec de petits montants avant de monter en charge.
Trois fondamentaux à retenir :
Le locktime correspond à une période pendant laquelle vos fonds sont gelés on-chain : vous ne pouvez ni transférer ni utiliser ces actifs avant la maturité. Après expiration, les fonds se déverrouillent automatiquement et deviennent utilisables. Ce mécanisme est courant dans les rendements DeFi et le vesting de tokens, afin de protéger les intérêts des investisseurs.
Les locktimes sur exchange varient selon le type de produit : les rendements sont souvent associés à des durées de 30, 90 ou 180 jours. Les périodes de verrouillage plus longues permettent en général d’obtenir des rendements annualisés supérieurs. Sélectionnez la période de lock sur Gate en fonction de vos besoins de liquidité.
La plupart des plateformes ne permettent pas le déverrouillage anticipé pendant la période de lock ; un retrait prématuré entraîne généralement la perte des récompenses ou des frais de pénalité. Certains produits proposent un déblocage anticipé payant, mais à coût élevé. Évaluez vos besoins de liquidité avant de vous engager dans un lockup.
Dans les protocoles de prêt DeFi, le locktime détermine le moment où vous pouvez retirer votre collatéral. Certains protocoles exigent que le collatéral reste verrouillé pendant une période donnée pour garantir la sécurité des prêts. Les déverrouillages anticipés peuvent entraîner des risques de liquidation ou des pénalités : à manipuler avec précaution.
Les règles de locktime varient fortement selon les tokens et les plateformes. Bitcoin et Ethereum disposent de mécanismes distincts ; les plateformes DeFi appliquent également des politiques différentes. Il est indispensable de consulter les conditions spécifiques de lock et de rendement pour chaque actif sur Gate ou tout autre exchange avant de participer.


