Nommer les quatre montants
Un tableau de vesting devient confus lorsque « disponible » désigne plusieurs choses. Séparez l’allocation prévue par le calendrier, les tokens effectivement déposés, le montant acquis à la date du calcul et le montant déjà retiré. N’affichez un montant retirable qu’après rapprochement avec le comportement réel du système. Signalez clairement un financement insuffisant. Le bénéficiaire ne doit pas deviner si un bouton à zéro signifie absence de droits acquis, retrait complet ou manque de tokens dans le contrat. Donnez les mêmes définitions à l’assistance.
Transformer le calendrier en exemples
Décrivez le début, le cliff, la durée et le rythme de libération dans un langage partagé par développeurs et bénéficiaires. Précisez si le cliff libère un montant accumulé ou démarre une nouvelle accumulation. Testez un instant avant la limite, la limite exacte et un instant après. Utilisez une allocation qui ne se divise pas exactement sur la période pour révéler les arrondis. Stockez les dates de manière cohérente et affichez leur fuseau. « Déblocage mensuel » ne suffit pas sans les dates et la règle de calcul.
Décider du sens des dépôts ultérieurs
La documentation OpenZeppelin de VestingWallet précise que les dépôts ultérieurs suivent le calendrier existant et peuvent être partiellement libérables immédiatement. Avec cette implémentation, traitez ce comportement comme un choix produit. Un complément destiné à une nouvelle attribution peut nécessiter un calendrier distinct. Enregistrez l’objectif, le bénéficiaire, l’identité du token et le calendrier attendu avant le dépôt. Présentez à l’opérateur son effet immédiat sur le montant retirable. Testez les dépôts précoces et tardifs pour éviter qu’une opération de trésorerie ordinaire ne produise une libération inattendue.
Décrire les changements et les pouvoirs
Documentez le changement éventuel de bénéficiaire, le transfert des droits et les possibilités de résiliation ou de modification. Ce sont des choix d’implémentation, jamais des propriétés à déduire d’une interface. Indiquez qui peut demander un changement et qui peut l’autoriser. Conservez le calendrier initial et la raison de chaque modification approuvée. Confirmez les adresses avec une procédure contrôlée plutôt qu’en recopiant un message non vérifié. Une procédure de récupération doit préciser ses limites, notamment lorsque le contrat déployé ne permet pas d’annuler une action antérieure.
Rendre les retraits vérifiables
Pour chaque retrait, conservez le calendrier, le réseau, l’actif, le destinataire, le montant, la transaction et son état observé. Une transaction en attente doit le rester jusqu’à satisfaction de la règle de vérification choisie. La répétition d’une demande ne doit pas créer une seconde tentative inexpliquée. Affichez l’heure du dernier rapprochement près des soldes calculés, surtout si l’indexeur est en retard. Les opérateurs ont besoin des écarts ; les bénéficiaires ont besoin d’une explication simple et d’une prochaine étape utile. Les deux vues doivent partager les mêmes preuves.
Préparer le jour du déblocage
Avant la première échéance, répétez les contrôles de financement, les questions clients, une panne de fournisseur et un retrait près d’une limite. Documentez les responsables et les traces à examiner. Testez les portefeuilles, les petits écrans, la précision des nombres et les dates traduites. Séparez le calendrier de toute promesse sur la valeur ou la liquidité. Le dossier de réception doit réunir exemples de calcul, permissions, rapprochements et limites de récupération. Un produit exploitable explique ce qui peut arriver, démontre ce qui est arrivé et donne une procédure reproductible à son équipe.