Types d’arnaques
Audit-badge laundering
An old audit is displayed after code, proxies or administrators have changed.
Les enquêtes et les fiches de référence sont publiées en anglais. La navigation est disponible en sept langues.
Personnes et projets
Dans cet article
An audit describes a defined system at a particular time
An audit badge becomes misleading when readers are encouraged to apply a limited historical review to a different live system. The report may be genuine while the inference drawn from it is false. A review of a token contract does not automatically cover a lending application that later uses the token, a replacement implementation or the people operating a withdrawal service.
Ethereum’s security documentation treats independent audits as an additional review, not a guarantee that every defect has been found. It also explains how upgrade patterns can change the logic used behind an existing address. A stable address therefore does not, on its own, prove that the reviewed code is still the code executing today. Ethereum documentation: audits and upgrade mechanisms.
Match the report to the deployed target
Start with the report itself. Record its date, author, scope, exclusions, repository revision and the contracts it identifies. Then compare these with the live chain and deployed addresses. Where a proxy is involved, identify both the proxy and the implementation relevant to the reviewed period. The report’s unresolved findings matter as much as the badge displayed above the deposit button.
Consider a hypothetical vault whose first implementation was reviewed before launch. A later implementation adds a new external call and changes who can update the fee recipient. The old report remains evidence about the old review. The current assessment must account for the changed logic and permissions. Describing the whole vault as “audited” without identifying the version conceals exactly the differences a depositor needs to understand.
Separate code findings from operational claims
A contract review may not include the website, DNS account, signing devices, administrator procedures or an external price service. These exclusions are not automatically negligence by the auditor: they can be outside the agreed engagement. The problem is presenting the resulting report as if those systems were examined. Read the scope before attributing either reassurance or blame.
The same distinction applies to fixes. A project saying “all issues resolved” should be compared with the actual retest record and deployed version. A commit labelled as a fix is an implementation claim. Evidence that the original failure no longer occurs under the tested conditions is a separate result. If a report contains accepted risks or unresolved findings, retain those qualifications when summarising it.
Document the mismatch precisely
A useful finding states the advertised assurance, the report that was linked, the deployed target checked and the mismatch between them. Preserve the badge page and report so a later edit cannot erase the context. Do not accuse an auditor of approving code they never reviewed. Equally, a project cannot extend an auditor’s work to new components simply by leaving the same logo on its homepage.