A smart-contract audit is a structured attempt to discover how a contract can fail, be misused, or be controlled in a way users did not expect. It is not the same as running one scanner, reading an audit badge, or confirming that source code is verified. Use the workflow below to review a deployed EVM contract or a codebase before you trust it with meaningful funds.
Important: This is a practical review framework, not a guarantee that a project is safe and not investment advice. A production protocol holding substantial value should receive an independent review by experienced security professionals. The interface-style images in this guide are illustrative and should not be treated as evidence about any particular project or deployment.
| Step | Primary question | Useful evidence |
|---|---|---|
| 1. Scope | Am I reviewing the exact contract that users call? | Address, chain, bytecode, proxy and implementation |
| 2. Entry points | What can each caller do? | Public/external functions, state changes, call graph |
| 3. Automation | What obvious patterns deserve attention? | Compiler output, Slither findings, detector triage |
| 4. Manual security | Can a call sequence break assumptions? | External calls, reentrancy, callbacks, failure handling |
| 5. Logic | Does the accounting remain correct at edge cases? | Arithmetic, rounding, fees, limits, state transitions |
| 6. Privileges | Who can change or stop the system? | Roles, owner, admin keys, proxy, initializer |
| 7. Testing | Does behavior hold across unexpected inputs and sequences? | Unit, fuzz, invariant and fork tests |
| 8. Reporting | Can another person reproduce and retest the result? | Finding, impact, evidence, fix and retest status |
Start with the exact chain and address. Record the deployment address, transaction hash, block number, compiler version, optimizer settings, constructor arguments, and the commit or release that the team says is deployed. A project may have several addresses for a token, router, vault, proxy, implementation, oracle, or test deployment. A review of the wrong address has no practical value.
Check whether the explorer’s verified source reproduces the deployed bytecode. Verification is useful because it lets you inspect source and ABI, but it is only an identity check: it does not prove that the business logic is safe. If the contract is upgradeable, identify both the proxy and its current implementation. Read the implementation address from the proxy’s documented mechanism or explorer information, then confirm that the implementation is the one you intend to review. Etherscan’s official Foundry verification guide documents verification for new and existing contracts.
Also define the boundary. Include imported libraries, inherited contracts, linked libraries, deployed helper contracts, oracle adapters, tokens received from users, and privileged off-chain components. Write down what is out of scope and why. This prevents a narrow review from being mistaken for a review of the complete system.
List every public and external function, including inherited functions and fallback or receive handlers. For each one, record whether it can:
Then map the assets and trust boundaries. Follow a deposit from the user into storage, through pricing and share calculation, to withdrawal. Identify every address supplied by a caller and every address loaded from storage. Ask which values are assumed to be honest: an oracle, a token, a bridge message, a keeper, a callback receiver, or an administrator. The highest-value review targets are functions that combine user-controlled input, privileged state, arithmetic, and an external call.
Reproduce the project’s build with the stated Solidity version, dependency versions, optimizer configuration, and target chain assumptions. Treat compiler warnings as review items rather than harmless noise. Solidity’s security considerations specifically recommend taking warnings seriously, keeping contracts understandable, and checking known compiler issues. Consult the official list of known Solidity compiler bugs when the compiler version or affected code patterns make it relevant.
For a Hardhat, Foundry, or similar project, run Slither from the project root. Its official documentation describes the tool as a Solidity and Vyper static analyzer and gives the common command:
slither .Enregistrez les résultats et triez-les par impact et niveau de confiance. Examinez attentivement les résultats concernant les envois de jetons arbitraires, les mises à niveau non protégées, la réentrance, les valeurs de retour non vérifiées, les appels délégués dangereux, l'origine des transactions (tx.origin), l'aléatoire faible et les interfaces incorrectes. Un détecteur peut générer un faux positif, manquer une faille économique spécifique au projet ou signaler du code intentionnellement contraint ailleurs. L'analyse statique affine la recherche ; elle ne remplace pas le raisonnement manuel. Le dépôt et la documentation de Slither répertorient également des outils d'impression pour les points d'entrée, l'autorisation, les graphes d'appels et les résumés de contrats, facilitant ainsi l'organisation de l'analyse.
Pour chaque appel externe, interrompez et suivez l'état du système avant, pendant et après l'appel. Le destinataire peut être un contrat malveillant, un jeton avec des hooks, un récepteur de rappel ou un autre protocole modifiant une dépendance partagée. La documentation de Solidity explique qu'une interaction avec un autre contrat peut lui en céder le contrôle et recommande le modèle « Vérifications-Effets-Interactions » : validez d'abord, mettez à jour l'état du contrat en second lieu, puis interagissez avec l'extérieur en dernier lieu.
Ne limitez pas la recherche aux transferts Ether évidents. Examinez les hooks de type ERC-777, les rappels ERC-1155, les rappels de prêts flash, les routeurs arbitraires, les appels d'oracle et les appels effectués via des bibliothèques héritées. Vérifiez la réentrance inter-fonctions et inter-contrats : un rappel peut entrer dans une autre fonction qui lit un état intermédiaire. Assurez-vous que chaque appel de bas niveau vérifie son résultat de succès et traite correctement la valeur de retour. Demandez-vous si un destinataire défaillant peut bloquer définitivement les retraits ou une boucle.
Consignez une séquence d'attaque concrète pour chaque problème plausible. Par exemple : l'attaquant effectue un dépôt, lance un retrait, reçoit une confirmation, effectue un second retrait, puis autorise la fin du premier. Si la séquence est impossible à reproduire en raison d'un invariant ou d'une mesure de sécurité spécifique, notez-en la raison. Ainsi, la conclusion sera vérifiable et non spéculative.
Vérifiez la signification de chaque unité et conversion : wei et ether, décimales des jetons, points de base, actions et actifs, valeurs signées et unités de temps. Respectez le sens d’arrondi. Une division arrondie en faveur d’un déposant, d’un emprunteur, d’un liquidateur ou d’un bénéficiaire de frais peut entraîner une perte de valeur lors de sa répétition. Examinez la multiplication avant la division, les montants minimum et maximum, les plafonds de frais, les prix obsolètes, l’offre nulle, le solde nul et l’identité du premier déposant ou du dernier retrait.
Solidity 0.8 et versions ultérieures détectent normalement les dépassements de capacité arithmétiques (overflow et underflow), mais le code à l'intérieur d'un uncheckedbloc peut modifier délibérément ce comportement. Des opérations arithmétiques vérifiées peuvent également entraîner un dysfonctionnement du protocole ou le rendre inutilisable si les limites ne sont pas correctement définies. Il est important de tester les deux cas de figure : vol de données ou erreur de comptabilisation, et déni de service dû à une valeur impossible à traiter.
Rédigez les invariants en langage clair avant de les transformer en tests. Par exemple : « le nombre total d’actions correspond aux actifs selon la règle d’arrondi spécifiée », « un utilisateur ne peut pas retirer plus que le montant enregistré », « l’offre totale de jetons est égale à la somme des soldes lorsque ce modèle s’applique » et « les frais ne peuvent pas dépasser le plafond configuré ». Comparez les soldes de stockage avec les soldes réels de jetons, car ces derniers peuvent être envoyés directement à un contrat ou se comporter différemment de l’implémentation ERC-20 supposée.
Élaborez une matrice des privilèges. Pour chaque fonction administrative, identifiez le rôle requis, le détenteur actuel, le mécanisme de transfert, le délai, le contrôle de signature multiple ou de gouvernance, et le comportement en cas d'urgence. Portez une attention particulière à la création, la suspension, la modification des frais, le changement de source d'oracle, la récupération de fonds, la mise à jour du code et la modification des adresses des jetons de confiance ou des routeurs. La documentation d'OpenZeppelin sur le contrôle d'accès distingue la simple propriété des permissions basées sur les rôles et décrit le principe du moindre privilège comme une pratique de sécurité utile.
Distinguez les actions autorisées à un administrateur de celles qu'un utilisateur lambda peut effectuer. La première peut présenter un risque explicite de gouvernance ou de sécurité ; la seconde, une vulnérabilité d'autorisation. Vérifiez que les contrôles de rôle couvrent tous les chemins sensibles, y compris les fonctions internes accessibles depuis les fonctions publiques. Assurez-vous qu'un administrateur par défaut peut s'octroyer ou octroyer à d'autres des pouvoirs supplémentaires et que le transfert de propriété n'est pas susceptible d'être envoyé par erreur à une adresse inutilisable.
Pour les proxys, examinez l'initialiseur, l'autorisation d'implémentation, le délai de mise à jour, l'organisation du stockage et le plan de restauration ou d'urgence. Les recommandations d'OpenZeppelin concernant les contrats évolutifs expliquent pourquoi les constructeurs n'initialisent pas le stockage du proxy, pourquoi les initialiseurs doivent être protégés, pourquoi une implémentation ne doit pas rester non initialisée et pourquoi toute modification de l'ordre ou des types de stockage peut corrompre une mise à jour. Considérez la clé d'administration du proxy comme faisant partie intégrante du périmètre de sécurité du protocole, et non comme un détail d'implémentation.
Exécutez des tests unitaires pour vérifier le comportement attendu, puis ajoutez des tests de comportement négatif pour les appels non autorisés, les valeurs nulles, les valeurs maximales, les signatures expirées, les données d'oracle obsolètes, les transferts ayant échoué et les opérations répétées. Testez la robustesse des entrées plutôt que de vous limiter à quelques valeurs triées sur le volet. Intégrez plusieurs acteurs et des contrats de réception malveillants lorsque la conception permet les rappels.
Utilisez des tests d'invariance pour les propriétés qui doivent rester vraies après de nombreux appels aléatoires. La documentation de Foundry sur les tests d'invariance décrit les séquences aléatoires, les entrées fuzzées, les exécutions, la profondeur, les contrats cibles et les expéditeurs cibles. Configurez les gestionnaires pour que les appels soient pertinents ; si chaque dépôt fuzzé est annulé parce que l'acteur de test ne possède aucun jeton, un test d'invariance réussi peut simplement signifier qu'aucun état utile n'a changé.
Dans la mesure du possible, utilisez une copie du réseau cible pour tester les adresses déployées, la configuration actuelle, le comportement des jetons et le routage proxy. Conservez les tests de la copie en lecture seule, sauf si vous utilisez une copie locale isolée. Minimisez chaque séquence d'échec et préservez le contre-exemple, les adresses de l'appelant, le contexte des blocs, les soldes et les valeurs de stockage pertinentes. Un test réussi témoigne de la validité des chemins testés, mais ne prouve pas la validité de tous les chemins possibles.
Utilisez un enregistrement par problème. Une constatation pratique doit contenir :
La gravité doit refléter l'impact réel et la vulnérabilité exploitable, et non l'apparence alarmante d'un schéma de code. Expliquez les hypothèses. Un appel de bas niveau peut être sûr grâce à un invariant fort ; une modification de paramètre apparemment anodine peut être critique si elle contrôle un oracle ou une mise à niveau. Après une correction, examinez les différences, relancez le test concerné, relancez la suite complète de tests et vérifiez l'absence de régressions. Si l'adresse déployée a déjà été mise à niveau ou modifiée, testez à nouveau l'implémentation et la configuration sur la blockchain.
Vous devriez pouvoir répondre oui à ces questions :
Si la réponse est négative, indiquez que l'audit est incomplet et précisez les éléments manquants. Une limitation claire est plus utile qu'une conclusion vague de « sécurité ». La sécurité des contrats intelligents est un processus continu : chaque mise à jour, modification de dépendance, nouvelle intégration et changement de privilège peut créer un nouveau périmètre d'audit.
Apprenez à répartir vos cryptomonnaies en fonction de votre tolérance au risque, de votre horizon temporel, de votre diversification, de la conservation de vos actifs, de votre liquidité et de votre rééquilibrage, sans vous fier à une formule unique.
Learn how to audit a crypto project’s smart contract step by step, from verifying the deployment and mapping permissions to testing logic, upgrades, and fixes.
Constituez un portefeuille de cryptomonnaies à long terme avec un cadre axé sur la gestion des risques pour l'allocation, la sélection des actifs, la conservation, la discipline d'achat, le rééquilibrage, la tenue des registres et la prévention des arnaques.
Apprenez à lire les données de la blockchain, à suivre les portefeuilles des baleines, à évaluer les labels de monnaie intelligente et à distinguer les faits vérifiables de la blockchain des inférences avant d'agir sur l'activité des portefeuilles.
Learn why crypto futures platforms show an “Insufficient Margin” error, how to diagnose the cause, fix it safely, and avoid margin problems before placing your next trade.
Découvrez le fonctionnement de Binance Launchpad et Launchpool, comment vérifier votre éligibilité, vous inscrire en toute sécurité, suivre vos récompenses et comprendre les limites et les risques.
Découvrez ce que signifie « dépassement de la tolérance de glissement » sur les CEX et les DEX, comment vérifier si une transaction a échoué et quand actualiser, réduire la taille, utiliser un ordre à cours limité ou ajuster la tolérance.
Découvrez le fonctionnement du copy trading avec Bybit, comment évaluer les Master Traders, définir les paramètres de copie, gérer les risques et surveiller les transactions perpétuelles USDT copiées.
Découvrez comment l'offre, la demande, les déblocages, les émissions, les destructions et l'utilité des jetons peuvent affecter le prix d'une cryptomonnaie, et ce que la tokenomics ne peut pas prédire.
Apprenez à comparer le volume des cryptomonnaies à sa valeur de référence, à confirmer les ruptures de prix, à repérer les essoufflements de la dynamique et à éviter de confondre un pic manipulé avec une force haussière.
