Prepare the evidence
Include published audit reports, public technical work such as GitHub activity and the company's audit specializations.
For smart contract security companies
Membership decisions are based on public, checkable evidence of smart contract security work.
Include published audit reports, public technical work such as GitHub activity and the company's audit specializations.
Keep report links and repositories accessible. Keep the organization and contact details current. Reviewers may compare the evidence with current member standards and request clarification.
The published review window is at least . After a rejection, a company may reapply in with updated evidence and a clear account of what changed.

Audit deliverables
An audit report explained properly starts at the scope statement and the dates, not at the findings table. Everything below those pages is conditional on them: which files were read, in what window and under which severity rule the firm writes its labels. This guide walks a real published report end to end, and measures the severity and status vocabulary that member firm reports actually use.

Audit deliverables
A fake audit report is a document that claims a security review which never happened, or a real report that no longer describes the code you are about to use. Both are caught the same way, by checking the report against the two things it should name: the commit that was audited and the deployed address it maps to. This guide gives the procedure, and a measurement of how often published reports carry those anchors at all.

Choosing a security firm
The top 10 cybersecurity companies below are ranked for one buyer: a team shipping a product that has smart contracts on one side and a web application, an API and a cloud account on the other. Each entry was checked on September 3, 2026 against the firm's own published material, and the three archives that sit on GitHub were counted through the API rather than estimated. One of the ten publishes price bands and lead times before the sales call, and the other nine quote on request.

Disclosure and bounties
A security disclosure policy is the published set of rules that tells a researcher where to send a vulnerability report, what they may test and what happens next. On September 2, 2026, only 3 of the 30 largest DeFi protocols by TVL served a security.txt file, and one of those three met RFC 9116. This guide gives protocol teams the policy wording, the file, the SEAL Safe Harbor steps and the response deadlines, each tied to a published source or to the terms real adopters set.

Tooling
Fuzzing generates inputs and call sequences against compiled contracts and checks that stated properties hold. Echidna, Medusa and Foundry all do smart contract fuzzing, with different default budgets, coverage guidance, shrinking and setup cost, so the right pick depends on whether the bug you fear needs one input or a sequence of calls. This guide gives the decision path, a settings matrix from each tool's current documentation, and a scan of what the 30 largest DeFi protocols actually keep in their repositories.

From the archive
Discover key insights and navigate the complex world of smart contract auditors with our article on the Quadrant Analysis.

From the archive
Discover 2023's best value smart contract auditors: Expert, affordable firms ensuring your blockchain's integrity and security.

From the archive
Discover the fusion of AI and blockchain in Web3 security, unlocking new possibilities to fortify decentralized applications.
DeFi Security Alliance
DeFi Security Alliance guidance
Answers for teams commissioning an audit and security companies considering DSA membership.
Reviewed
A smart contract audit is a scoped review of a specific code version. Reviewers examine access control and state or accounting logic. They also assess external calls and integrations as well as upgrade paths and chain-specific assumptions. A useful report identifies the reviewed scope and commit. It records each finding with its severity and affected code. The report also states the remediation status. See the smart contract audit reports collected by DSA.
No. An audit reduces risk within the agreed scope, but it is not a security guarantee. Code outside the scope, later changes, a deployed version that differs from the reviewed commit, privileged key handling and economic or oracle assumptions may remain outside the review. Before launch, confirm that the deployed code matches the audited version and that reported fixes were retested.
Schedule an audit after the intended release is feature complete and its build instructions, tests and documentation are ready, but before production deployment. Leave enough time to fix findings and complete a remediation review. Significant code changes after the audit may require additional review.
Match the auditor's evidence to your technology and risk profile. Review public reports for experience with your chain and language as well as your protocol type. Look for explicit scopes and commit identifiers. Check the severity definitions and remediation results. Confirm who will review the code and what is excluded. Ask about the schedule and retest terms. Start with the DSA auditor directory.
Send a bounded and reproducible scope. Include the repository and the branch or commit. Identify the contracts in scope as well as the languages and chains. Provide architecture notes and threat assumptions. Include the build or test commands. Describe privileged roles and the deployment plan. Add the preferred review window and any earlier reports. These details help an auditor estimate effort and explain exclusions. You can begin with the audit request form.
There is no reliable flat price for every smart contract audit. Cost depends on scope size and complexity, language and chain, integrations, code maturity, schedule, reviewer count and whether remediation review is included. Compare written proposals by scope, exclusions, deliverables and retest terms instead of headline price alone.
Smart contract security and auditing companies with a verifiable public track record can apply. An application should identify the organization and its technical specializations. It should also link to public audit reports and other relevant security work. Submit the current evidence through the membership application.
Membership status is reviewed annually. DSA can reconsider whether a member's activity and public evidence continue to meet alliance standards. The membership badge identifies the relevant membership year.
DSA does not publish a fixed public membership fee. Request the current terms through the membership application or contact form before relying on any cost assumption.
A member can receive an alliance directory profile and membership badge. Members can share relevant security work and participate in the alliance's knowledge exchange. Available programs and tools can change. Review the current Audit Builder information and contact DSA for the terms that apply to a new member.