Je regarde actuellement le projet « crédibilité » en me concentrant d'abord sur trois aspects : GitHub, rapport d'audit, mise à jour/multisignature.

Ne vous contentez pas de regarder les étoiles sur GitHub, vérifiez d'abord si le projet est toujours actif récemment, si des issues ont reçu des réponses, si les modifications clés sont une série de merges temporaires…
Ce genre de changements majeurs après six mois sans mise à jour, je préfère d'abord retirer les permissions.
Les rapports d'audit ne doivent pas non plus être considérés comme un passe-droit, concentrez-vous sur « corrigé/non corrigé » et la portée, beaucoup d'audits ne couvrent qu'une partie des contrats, la logique de mise à jour étant en fait la plus susceptible d'être oubliée.

La mise à jour avec multisignature est plus réaliste : qui gère la clé, combien de signatures pour le seuil, y a-t-il un timelock.
Si vous pouvez modifier la mise en œuvre à tout moment sans délai, c'est comme si vous confiez le portefeuille à quelqu'un d'autre.

Que faire si l'outil de balisage on-chain est en retard ou peut induire en erreur ?
Ne vous fiez pas uniquement aux balises, vérifiez vous-même la liste d'autorisation et les permissions du contrat, au moins en avoir une idée claire.

De toute façon, ma propre habitude : pour un nouveau protocole, je commence par de petites sommes, avec des autorisations limitées, et dès que je vois une autorisation illimitée, j'ai envie de la retirer, même si c'est plus compliqué.
C'est comme ça pour l'instant.