How to Assess Web3 Project Risks: A Practical User Checklist

In Web3, users often hold their own keys and sign transactions directly. A useful review therefore starts not with “How much can I earn?” but with: What am I signing, which code will gain access to my assets, and who can change the rules?

Aucune liste de contrôle ne peut prouver qu’un projet est sûr. Son but est de révéler les inconnues, de comparer les affirmations aux éléments vérifiables et de limiter les dommages potentiels.

Cet article est fourni uniquement à des fins pédagogiques et ne constitue ni un conseil financier, ni un conseil en investissement, ni un conseil juridique. Les transactions Web3 peuvent entraîner la perte totale des actifs transférés.

1. Vérifier la source

• Utilisez un favori enregistré ou une URL provenant d’un canal officiel vérifié.
• Vérifiez chaque caractère du nom de domaine.
• Évitez de connecter un portefeuille depuis une publicité, un message non sollicité ou un résultat de recherche choisi au hasard.
• Comparez les adresses des contrats dans les différents documents officiels du projet.
• Ne communiquez jamais une seed phrase ni une clé privée.

Stop signal: a site asks you to “synchronize,” “validate,” or “restore” a wallet by entering secret words.

2. Confirmer le réseau et l’actif

Avant tout transfert, notez :

• réseau ;
• adresse du contrat du jeton ;
• adresse du destinataire ou du contrat appelé ;
• montant ;
• actif utilisé pour payer les frais ;
• action prévue.

A name such as USDT does not uniquely identify a token. Verify the full token contract address. The same 0x… address format can be used on different EVM networks, but assets and state remain network-specific.

Stop signal: the project gives a ticker but does not publish the network and token address.

3. Examiner le code déployé

Dans un explorateur de blocs :

• trouver le contrat à l’aide de l’adresse officielle ;
• vérifier le code source ;
• déterminer s’il s’agit d’un proxy ;
• ouvrir l’implémentation actuelle ;
• comparer toutes les adresses à la documentation du projet.

On BscScan, Exact Match means published source and constructor parameters were matched to deployed bytecode. This improves transparency but is not a security assessment.

Stop signal: no address is published, source is unverified, and the project still claims “full transparency” without explanation.

4. Comprendre les pouvoirs administratifs

Recherchez des rôles et fonctions tels que :

• propriétaire, administrateur, opérateur et responsable des mises à niveau ;
• suspendre et reprendre ;
• modifications des frais ou des limites ;
• modifications des adresses associées ;
• création de jetons ;
• retrait d’actifs ;
• mises à niveau de l’implémentation ;
• le blocage d’adresses.

Demandez qui contrôle ces clés, si un mécanisme multisignature est utilisé, si les modifications sont soumises à un délai d’attente et comment les utilisateurs sont informés. Un contrôle centralisé n’est pas automatiquement frauduleux, mais il crée une dépendance envers des responsables précis.

Stop signal: one address holds critical powers while the project claims that nobody can change anything.

5. Lire correctement l’audit

Vérifiez si :

• le rapport est publié par l’auditeur ;
• le dépôt et le hash du commit sont indiqués ;
• le contrat actif est inclus dans le périmètre ;
• le rapport couvre l’implémentation actuelle ;
• des constatations non résolues subsistent ;
• les corrections ont été testées à nouveau ;
• des composants importants ont été exclus.

Un audit est un examen indépendant supplémentaire. Il ne peut pas détecter tous les défauts et ne couvre pas automatiquement le site web, la gestion des clés, le modèle économique ou les futures mises à niveau.

Stop signal: there is an “Audited” badge but no report or reviewed code version.

6. Comparer les demandes d’assistance au comportement on-chain

Examinez plusieurs transactions pour vérifier :

• état ;
• De et To / Interacted With;
• mouvements BEP-20 ;
• appels internes ;
• journaux ;
• frais ;
• modifications des soldes et de l’état du contrat.

Compare the actual path of funds with the published architecture. Do not draw a system-wide conclusion from one demonstration transaction. Succès means the code executed without reverting; it does not mean the operation was safe or beneficial.

Stop signal: observable fund flows differ from the stated process and no clear explanation is provided.

7. Distinguer les actifs des passifs

Le solde visible d’une adresse n’est qu’un élément. Demandez-vous :

• toutes les adresses pertinentes sont-elles divulguées ;
• qui contrôle les actifs ;
• peuvent-ils être retirés ;
• quelles obligations existent envers les autres utilisateurs ;
• méthode de détermination d’un prix externe ;
• si l’accès dépend d’un pont, d’un DEX, d’un oracle ou d’une contrepartie.

Un solde élevé de jetons ne prouve pas l’existence d’une liquidité suffisante. Un grand nombre d’unités peut n’avoir qu’une faible valeur réalisable.

Stop signal: one address balance is presented as proof of solvency without disclosing obligations or control rights.

8. Expliquer le modèle économique en termes simples

Trouvez des réponses claires aux questions suivantes :

• d’où provient chaque versement ;
• qui paie les frais ;
• ce qui se passe si aucun nouvel utilisateur n’arrive ;
• conditions de sortie et périodes de verrouillage ;
• où des pertes peuvent se produire ;
• quels paramètres les administrateurs peuvent modifier ;
• ce qui détermine le prix du jeton.

Si le résultat dépend des marchés, de nouveaux participants, de la liquidité ou des décisions de l’équipe, ces dépendances doivent être indiquées explicitement.

Stop signal: a fixed outcome is promised without a verifiable source of funds or loss scenario.

9. Contrôler les signatures et les autorisations de jetons

Avant de confirmer, vérifiez ce que le portefeuille affiche :

• réseau ;
• adresse appelée ;
• fonction ou action lisible ;
• valeur en actif natif ;
• jeton et montant de l’autorisation ;
• modifications d’actifs attendues.

An approve call does not immediately transfer a token. It may authorize a spender contract to call transferFrom up to an allowance. An unlimited allowance increases potential loss if the spender is compromised or flawed.

Refusez une signature si les données ne sont pas claires ou si l’adresse diffère de celle que vous avez vérifiée. Après utilisation, examinez et révoquez les autorisations devenues inutiles au moyen d’un outil fiable.

Stop signal: you are pressured to sign unreadable data or told that a signature “does nothing.”

10. Inclure les risques off-chain

Même un code soigneusement audité ne peut empêcher tous les :

• compromission du site web ou du DNS ;
• extension de navigateur malveillante ;
• vol de clés ;
• compte du projet compromis ;
• défaillance du système dorsal ;
• attaque par ingénierie sociale ;
• restriction juridique ;
• défaillance de l’assistance ou des opérations.

Examinez la documentation, les procédures de gestion des incidents, les canaux de notification et l’historique des modifications. Évaluez les affirmations juridiques à partir des documents réels et selon votre propre juridiction.

11. Limiter les dommages potentiels

Même après avoir terminé l’examen :

• commencer par le plus faible montant de test possible ;
• utiliser un portefeuille distinct pour les dApps inconnues ;
• ne pas conserver tous les actifs dans le portefeuille connecté ;
• ne jamais signer sous la pression du temps ;
• enregistrer les hash de transaction et les adresses ;
• examiner régulièrement les autorisations de dépense de jetons ;
• définir une exposition maximale dont la perte totale resterait supportable.

Les recommandations officielles de sécurité de Solidity préconisent de limiter le montant des actifs détenus dans un contrat : si le code, le compilateur ou la plateforme contient un bug, limiter l’exposition peut réduire la perte.

Liste de contrôle avant transaction

Answer yes, no, or unknown:

• J’ai vérifié le domaine.
• Je connais le réseau exact.
• J’ai vérifié l’adresse du contrat du jeton.
• J’ai vérifié l’adresse du contrat appelé.
• Je connais le statut de vérification du code source.
• J’ai vérifié le proxy et l’implémentation.
• Je comprends les pouvoirs des administrateurs.
• L’audit correspond à la version actuellement déployée.
• J’ai examiné des transactions réelles.
• Je comprends la source des versements et les scénarios de perte.
• Je comprends la demande de signature.
• L’autorisation de dépense est limitée de manière raisonnable.
• J’ai pris en compte les risques liés à l’interface, aux clés et au cadre juridique.
• Le montant de test ne doit pas pouvoir causer de préjudice critique.

For a critical question, unknown is not a neutral answer—it is an unassessed risk. Pausing for verification is usually cheaper than an irreversible transaction.

Questions qu’un utilisateur prudent doit poser

Is a project safe if its code is open and audited?
No. Those are useful signals, but unknown bugs and administrative, operational, economic, and external risks remain.

If assets are visible on-chain, can they definitely be returned?
No. Return depends on code, current state, control rights, and external dependencies.

Does a small successful test prove a larger transaction will work?
No. It tests one path at one moment. Limits, liquidity, state, and implementation may later differ.

What if I do not understand the signature?
Reject it. Identify the function, called address, asset changes, and permissions before trying again.

Sources et lectures complémentaires

1. Solidity Documentation — Considérations de sécurité
2. Ethereum.org — Sécurité des smart contracts
3. Ethereum.org — Test des smart contracts
4. BscScan Information Center — Consulter les transactions
5. BscScan Information Center — Types de vérification des contrats
6. BscScan Information Center — Qu’est-ce qu’une adresse ?
7. OpenZeppelin Docs — Modèle de mise à niveau par proxy