Security research
Importance of the security audit for DeFi projects
A DeFi security audit adds independent review of a defined revision. Its value depends on the scope, the treatment of findings and evidence that the reviewed code matches the release. This guide explains how to check those links and reproduce a small synthetic example.
Why a DeFi project needs independent review
A lending pool, token or vault exposes rules that other participants can call. A mistake in authorization or accounting can therefore affect users who had no role in writing the code. Independent reviewers bring another opportunity to find errors before release. Ethereum's security guidance places audits alongside testing and other safeguards, and explicitly says audits cannot find every bug.
Prepare a scope-based audit RFP, then read audit scope, findings and follow-up status in the delivered report.
The useful output is a record of what was examined and what happened to the findings. A logo or an undated claim that a project is audited leaves those questions unanswered. For a team, the record supports release decisions. For an integrator or community member, it helps establish whether the published review applies to the contracts they are considering.
Start with the reviewed release and its boundaries
Identify the repository and commit named in the report, then locate the final revision covered by any fix review. A newer release needs an explanation of its changes. Merely retaining the same project name does not connect new code to an older review.
| Record | Question it should answer |
|---|---|
| Scope and commit | Which files and dependencies were reviewed, at which revision? What was excluded? |
| Assumptions | Which oracle behavior, permissions and external contracts does the design depend on? |
| Finding history | What changed for each issue, and which revision did the reviewer recheck? |
| Deployment record | Which chain and address run the reviewed code? Which configuration was applied? |
Mark missing records as unknown. A frontend, admin key or external service may fall outside the reviewed code. Ask explicitly whether those components received their own assessment. The DSA review methodology provides a framework for documenting evidence and limits.
Follow a finding through the fix review
A finding marked resolved should lead to a concrete change and a review of that change. Request the fix commit, the relevant test or reasoning, and the reviewer's final status. Record accepted risks separately from repaired defects.
For a public example of traceable reporting, OpenZeppelin's ERC-4337 incremental audit names an excluded contract and records fix review through commit 8086e7b. Individual resolution updates link to pull requests. This illustrates the structure to look for. It does not establish that another project, later release or different deployment received the same review.
Connect the report to the deployed contract
Source code verification checks whether supplied source and compilation settings reproduce the contract's bytecode. It provides a connection to an address that a report alone cannot provide. Ethereum's verification documentation distinguishes this from formal verification of specified behavior. A bytecode match does not demonstrate that the program is free of vulnerabilities.
Keep compiler settings and the verification result with the deployment record. Sourcify documents how metadata, linked libraries and immutable values affect matching. A simplistic comparison can miss these details. For an upgradeable system, also identify the current implementation and who can change it. A source match for a proxy does not establish that its current implementation was audited.
Worked example: three checks on four evidence packets
We created a synthetic teaching fixture on September 5, 2026. It contains one consistent reference packet and three copies, each with one changed field. The records represent a final reviewed commit, source fingerprints, a resolved finding with a retest record, and two runtime byte strings.
The Python checker compares the release commit and listed source fingerprints with the report. It checks that the retest record points to the finding's fix commit and final reviewed revision. It then compares the supplied build and deployment byte strings.
| Packet | Scope / commit | Retest record | Runtime bytes |
|---|---|---|---|
| Reference | Consistent | Consistent | Consistent |
| Different release commit | Mismatch | Consistent | Consistent |
| Stale retest record | Consistent | Mismatch | Consistent |
| Different runtime bytes | Consistent | Consistent | Mismatch |
The run produced 12 checks: 9 consistent results and 3 mismatches. These are counts for invented data, not a security score or a real-world detection rate. Commit labels are fictional, source strings are teaching notes, and runtime bytes are hand-authored. The checker reads a retest record without executing or authenticating it. It neither compiles contracts nor reads a blockchain.
To reproduce, save the checker and fixture together, then run:
python3 check_audit_evidence.py > reproduced-results.jsonCompare the output with our recorded results. Python 3.9 or later is sufficient. No third-party packages are needed. The exercise notes explain the limits. Matching records can still describe incomplete scope or unsafe code.
Keep the evidence current after release
Before deployment, assign an owner to every unresolved finding and document the release decision. After deployment, track upgrades and changes to privileged roles. Prepare monitoring and an incident response process, including who can act and which operations can be paused. Ethereum's security guidance treats recovery planning as part of the work that continues beyond code review.
Use the security tools directory to investigate analysis and monitoring options. When reading provider evidence reports, check the underlying artifacts and exclusions. The practical question remains specific: what evidence connects this reviewed revision to this deployment today?
Sources
Checked . Local examples include their inputs and limits.
About this revision
Revised on September 5, 2026: retained the subject and historical DefiMoon attribution, replaced service promotion with sourced guidance, and added a reproducible synthetic evidence exercise. The original contributor is not presented as the reviewer of this update.
Suggest a correction with evidence