Décrire les pouvoirs avant de choisir un modèle

Commencez la spécification par un tableau des pouvoirs. Pour chaque action sensible, indiquez son responsable, ses limites et la manière de changer cette autorité. Incluez l’émission, les restrictions de transfert disponibles, la configuration et les mises à jour autorisées. Une appellation familière de jeton n’explique pas ces détails. L’acheteur doit recevoir un comportement décrit simplement, en plus des interfaces techniques. Ce tableau guide aussi les écrans administratifs : chaque commande doit correspondre à une permission réelle, pas uniquement à un bouton pratique ajouté pour la démonstration commerciale.

Expliciter les règles d’émission

Discutez de l’offre souhaitée avant de choisir les contrôles d’émission. Les unités sont-elles créées une seule fois, libérées selon un calendrier ou ajoutées dans un processus métier régulier ? Précisez l’initiateur, les vérifications et la trace expliquant le motif. Distinguez une approbation opérationnelle des limites imposées par le contrat lui-même. Si un plafond est annoncé, la revue doit établir ce qui le fait réellement respecter. Demandez des cas aux frontières, notamment un montant trop élevé et une demande répétée, plutôt qu’une seule émission réussie en guise de preuve.

Distinguer gel, pause et restrictions de compte

Des libellés proches peuvent cacher des pouvoirs différents. Le modèle de jetons Solana comporte une autorité de gel ; d’autres implémentations proposent une pause ou une restriction spécifique. Ces mécanismes ne sont pas interchangeables. Définissez les comptes et opérations concernés, les personnes capables de lever la restriction et l’information donnée au client. Montrez un transfert tenté pendant la restriction puis après sa suppression. Pour cadrer le produit, le comportement exact vécu par le détenteur compte davantage qu’une case générique intitulée gel dans une longue liste de fonctions.

Examiner séparément le pouvoir de mise à jour

Une architecture à proxy peut permettre de remplacer la logique du contrat, ce qui crée une décision de gouvernance distincte du droit d’émettre. Identifiez l’autorité réelle de mise à jour et le processus d’examen d’une nouvelle implémentation. Comment les opérateurs et clients apprendront-ils un changement de comportement ? Quels contrôles de compatibilité précèdent le déploiement ? Si le jeton doit être non modifiable, vérifiez cette propriété dans l’architecture livrée. Conservez les adresses et versions déployées pour qu’un examen ultérieur puisse établir ce qui fonctionnait à une date donnée.

Traiter la suppression de droits comme une opération

La suppression d’un pouvoir peut être irréversible : Solana documente, par exemple, le retrait définitif d’une autorité sélectionnée lorsqu’elle est définie à None. Avant l’action, vérifiez réseau, adresse, rôle exact et fonctions qui deviendront indisponibles. Faites examiner le changement par les responsables de l’exploitation. Répétez la procédure dans un environnement approprié et gardez ses preuves. Retirer un administrateur ne signifie pas éliminer tous les chemins privilégiés : les autres rôles et droits de mise à jour doivent être analysés séparément, avec une vérification de l’état obtenu après l’opération.

Réceptionner les permissions réellement déployées

À la livraison, comparez le tableau prévu avec la configuration sur la chaîne. Vérifiez les titulaires des rôles, leur rotation, la perte d’accès et les décisions exceptionnelles. Demandez les étapes d’installation, les traces de déploiement, les informations de vérification et les tests d’actions interdites. La console doit rendre le réseau et la cible évidents avant une opération sensible. Une réception utile établit qui peut modifier le jeton aujourd’hui, comment cette situation peut évoluer et quelles limites l’équipe opérationnelle et les détenteurs doivent comprendre avant son lancement public.