Start with a locked review target
A DeFi audit is only useful if the reviewed code is the code you intend to deploy. Before you contact an auditor, lock a repository URL, exact commit hash, compiler and dependency versions, target networks, and every contract or program in scope. List generated code and third-party libraries separately so reviewers can separate owned logic from dependencies.
Make exclusions as explicit as inclusions. Frontends, keeper bots, bridges, oracles, indexers, and deployment scripts can change the real attack surface even when they are outside the core contract review. Recording those boundaries prevents the report from being read more broadly than the work performed.
Inventory privileged roles and irreversible actions
Document owners, multisigs, upgrade authorities, pausers, fee setters, minters, treasury roles, allowlists, emergency paths, and any function that can move assets or rewrite accounting. For each role, state who controls it at launch, how keys are protected, whether a delay applies, and how authority can be revoked or transferred.
Translate business rules into invariants: what must always remain true about balances, shares, collateral, rewards, supply, permissions, and state transitions. Invariants make manual review, fuzzing, and property tests more useful than a generic vulnerability checklist.
Describe integrations and failure modes
List tokens, price feeds, routers, callbacks, signature standards, account-abstraction components, off-chain services, and cross-chain message paths. State assumptions about decimals, fee-on-transfer behavior, rebasing, stale prices, finality, replay protection, callback behavior, and third-party downtime.
Reviewers need to see how the system fails, not only how it succeeds. Define expected behavior when an oracle is stale, an RPC is unavailable, a keeper misses a job, a token behaves unexpectedly, a transaction is partially executed, or an administrator needs to pause a subsystem.
Agree on findings, remediation, and retest before work starts
Define severity criteria, report format, communication channel, disclosure handling, expected patch window, and what a retest covers. A retest should reference the remediation commit and classify each original finding as resolved, partially resolved, accepted, or still open. Features added after the locked commit require separate review.
An audit reduces technical uncertainty. It does not guarantee that a protocol is free of defects, economic risk, or operational failure. Acceptance packages should include scope and commit, methods used, findings, remediation status, known limitations, test evidence, and deployment-specific checks.
Prepare release evidence for mainnet
Treat build, test, deploy, and public verification as separate release steps. Capture deterministic build output, automated tests, static analysis or fuzz results, deployment transaction receipts, verified source links, final role assignments, monitoring configuration, and an incident runbook.
Operators should be able to prove that the reviewed commit is the code released on-chain. Without that evidence trail, an otherwise strong audit report cannot support a safe launch decision.
How DappWeb runs a focused DeFi audit sprint
DappWeb combines threat modeling, manual review, AI-assisted triage, business-logic validation, patch guidance, and launch verification. AI helps with diffs, pattern detection, and test ideas. Human review remains required for privileged actions, economic assumptions, and production deployment decisions.
Teams that also need DApp, admin, indexer, or monitoring work can keep audit and engineering in one delivery path. DappWeb provides software and security services only. It does not custody assets, operate an exchange, sell tokens, or provide investment advice.
To start, send project type, target chain, repository URL, commit hash, launch date, budget range, and contact channel to admin@dappweb.ai, or use the project brief at https://dappweb.ai/contact/#project-brief.