Smart Contract Audit Methodology
A transparent audit workflow for teams that need manual security review, tool-assisted analysis, clear findings, remediation support, and a final report.
Audit Workflow
The process is structured, but each audit adapts to the codebase, ecosystem, and assets at risk.
Scoping
Confirm repositories, commit hashes, contracts, networks, exclusions, documentation, known risks, and disclosure requirements.
Architecture review
Understand assets at risk, trust boundaries, privileged roles, external dependencies, and the intended system invariants.
Automated analysis
Use static analysis, tests, fuzzing, symbolic execution, or custom checks where they improve coverage. Tools supplement manual review.
Manual code review
Trace value movement, access control, state transitions, external calls, upgrade paths, and chain-specific execution behavior.
Threat modeling
Model attackers, operators, integrators, governance, keepers, relayers, oracles, bridges, and market actors.
Business-logic analysis
Review assumptions that tools cannot infer: accounting, incentives, liquidation, governance, cross-chain state, and protocol economics.
Adversarial testing
Create targeted tests or reproductions for suspicious paths, edge cases, and exploit hypotheses.
Classification
Rank issues by practical impact, likelihood, exploitability, and remediation priority.
Reporting
Document findings with affected code, impact, remediation guidance, and context that engineers can use.
Remediation support
Answer implementation questions and review fixes against a new commit when included in scope.
Final report
Prepare a private or public report according to the agreed disclosure model.
Manual review comes first
Automated tooling can reveal known patterns, suspicious code, and edge cases. It cannot fully understand governance intent, economic invariants, cross-chain trust, oracle manipulation, or the business logic that makes a protocol valuable.
CTDSEC uses tools to increase coverage, then relies on manual security review to decide whether behavior is exploitable, meaningful, and worth fixing before launch.
Methodology deliverable
Every audit should leave the team with findings, context, remediation guidance, and a clear path to fix verification.
Scope and exclusions
The review needs a reproducible source reference: a repository commit or an identified source archive. Confirm which contracts, deployment configuration, libraries, oracle integrations, privileged roles, and external services are included. An integration review does not automatically cover the external protocol itself.
Agree on the disclosure model, documentation, test environment, known issues, and any unavailable components before work begins. Record limitations in the report so readers can distinguish reviewed code from assumptions.
Remediation and retesting
When fix verification is included in the engagement, supply the changed revision and a finding-by-finding response. Resolve means the reported issue was addressed within the reviewed change; acknowledged means the team accepted or noted the issue, not that a fix was verified.
New features, changed dependencies, and later upgrades may require additional scope. Confirm retest rounds and timing in the proposal. An audit reduces uncertainty but cannot guarantee vulnerability-free code.
Compare these distinctions in the URMCDP report and PWRAuctionCrossChain report.
Get a smart contract audit quote
Tell us what you are building and when you plan to launch. Start with a short description; repository access and technical scope can follow.