La troisième fois qu’un ami me demande « Ce projet est-il fiable ? », je ne regarde plus vraiment les chandeliers maintenant, je vais d’abord vérifier GitHub et le rapport d’audit. GitHub ne consiste pas à regarder le nombre d’étoiles, en gros il faut voir si les mises à jour sont régulières, s’il y a des traces de maintenance à long terme, si les changements importants sont expliqués, pas juste une grosse refonte avec une simple mention « refactor » pour faire semblant.

Le rapport d’audit ne doit pas se limiter à « approuvé / pas de problèmes majeurs », il faut vérifier si la liste des problèmes est précise, s’il y a des preuves de correction, et idéalement faire correspondre cela aux commits du code. Concernant la mise à niveau de la multi-signature, c’est aussi ce que les débutants oublient : qui peut signer, combien de signatures sont nécessaires pour agir, y a-t-il un délai (timelock), ces éléments déterminent si vous achetez un protocole ou simplement la humeur de l’administrateur.

Récemment, les étiquettes des outils de données on-chain ont encore été critiquées pour leur retard ou leur potentiel de confusion, je suis d’accord… donc je considère maintenant les « étiquettes » comme une référence, la « structure des permissions » et « les changements de code » comme la ligne de fond. Après avoir étudié tout ça, je ne passerai peut-être pas à l’achat, mais au moins je dormirai plus tranquille.