Audit badges are used in crypto marketing as a proxy for safety, which is a category error. An audit is a time-boxed review of a specific artefact by people with finite hours. It is evidence, and reading it properly gives you real information \u2014 but almost none of that information is contained in the word „audited“.<\/p>\n
A group of specialists reads your code for an agreed number of weeks and writes down what they found. That is the entire product. It is genuinely valuable \u2014 good auditors find things teams have stared past for months \u2014 and it is not a certification, a guarantee, or a statement that the system is safe.<\/p>\n
The distinction matters commercially as well as technically. An audit is evidence you can show a counterparty. A badge with no linked report is not evidence of anything, and treating the two as equivalent is how „audited“ became a marketing word rather than a technical one.<\/p>\n
Every report states what was reviewed. It is the section that matters most and the one nobody reads.<\/p>\n
Scope is typically a list of files at a specific commit hash. Anything not in that list was not looked at. This routinely excludes the deployment scripts, the off-chain components, the oracle integration, the governance contracts and any dependency \u2014 which is to say, it frequently excludes where the failure will occur.<\/p>\n
The commit hash is equally important. An audit covers the code as it existed at that commit. If the team shipped changes afterwards \u2014 and they nearly always do \u2014 that code is unaudited, whatever the badge says. Comparing the audited commit against what is actually deployed is a check anybody can perform and almost nobody performs.<\/p>\n
Resolved findings tell you the process worked. The informative section is the one listing issues marked acknowledged<\/em>, disputed<\/em> or risk accepted<\/em>.<\/p>\n Acknowledged means the team read it and chose not to change anything. Sometimes that is entirely reasonable \u2014 a theoretical issue with an impractical precondition. Sometimes it is a live risk the team decided to carry, disclosed in a document nobody reads. The reasoning is usually printed alongside it, and the quality of that reasoning is one of the better signals available about the team.<\/p>\n Centralisation findings deserve particular attention, because they are the most commonly acknowledged and dismissed. „The owner can pause withdrawals“ marked as acknowledged is not a formality; it is a description of the actual trust model.<\/p>\n There is no shared definition of „high“ or „medium“ across firms. One auditor’s high is another’s medium, and severity is frequently a negotiation between auditor and client. Comparing severity counts across reports from different firms tells you very little.<\/p>\n Read the description of each finding rather than the label.<\/p>\n Economic design flaws.<\/strong> Code that does exactly what it was specified to do, where the specification is exploitable. Most audits review implementation against intent, not intent against reality.<\/p>\n Emergent interactions.<\/strong> A contract can be individually sound and unsafe in composition with a protocol that did not exist at audit time.<\/p>\n Off-chain failure.<\/strong> Compromised keys, a bad deployment, a misconfigured multisig, an oracle that behaves fine until it does not.<\/p>\n Governance capture.<\/strong> Contracts working precisely as designed while control of them changes hands.<\/p>\n Is the full report published, or only a badge? What commit was audited and does it match production? What is in scope and, more usefully, what was excluded? How many findings were acknowledged rather than fixed, and what was the reasoning? Was there a re-review after the fixes, or is the report pre-fix? How long did the engagement run \u2014 a two-day review of a large codebase is a different product from a four-week one.<\/p>\n A team that publishes the full report including the uncomfortable findings is telling you something more valuable than the audit itself.<\/p>\n","protected":false},"excerpt":{"rendered":" How to read a smart contract audit report: scope, commit hash, severity handling and the questions that reveal whether an audit means anything.<\/p>\n","protected":false},"author":10,"featured_media":151,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[53,54,47,50],"class_list":["post-90","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-smart-contracts","tag-audits","tag-due-diligence","tag-security","tag-smart-contracts"],"_links":{"self":[{"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/posts\/90","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/comments?post=90"}],"version-history":[{"count":1,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/posts\/90\/revisions"}],"predecessor-version":[{"id":96,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/posts\/90\/revisions\/96"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/media\/151"}],"wp:attachment":[{"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/media?parent=90"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/categories?post=90"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tokenpr.net\/de\/wp-json\/wp\/v2\/tags?post=90"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Severity is not standardised<\/h2>\n
What an audit structurally cannot catch<\/h2>\n
Questions worth asking<\/h2>\n