3.12.7 Security Standards and Frameworks

For most of smart contract security's history, "what counts as secure" was a matter of expert judgment. A protocol team would hire an audit firm, the firm would apply its own internal methodology, the report would list findings, and the protocol would address them. There was no industry-wide standard for what an audit should check, no shared list of what a secure contract must do, and no agreed-upon framework for measuring or certifying security maturity. Two audits of the same contract by two reputable firms could produce substantially different reports because they were applying different implicit frameworks.

This has been changing. Over the past several years, multiple standards-development efforts have produced shared frameworks for smart contract security. OWASP's Smart Contract Security Project, the Enterprise Ethereum Alliance's EthTrust Security Levels Specification, the Smart Contract Weakness Classification, and several others now provide structured references that protocol teams, audit firms, and security researchers can align around. The frameworks don't replace expert judgment, and certification under them doesn't guarantee security, but they raise the floor and make security claims comparable across protocols.

This subsection covers what standards exist, what they cover, how they interact, and how a developer should use them in practice. The space is more settled than the other Section 3.12 topics — the major standards have stabilized and the question is increasingly which to apply, not whether to apply any. Standards adoption is one of the clearest signals that smart contract security is professionalizing as a discipline rather than remaining an artisan practice.

What Standards Are For

Standards in smart contract security serve four distinct purposes:

1. Vocabulary. Common terms for common bugs. A "reentrancy vulnerability" means something specific; "access control failure" means something specific. Without standards, the same bug might be called five different things in five reports. With standards, comparisons become possible.

2. Checklists. Lists of things to verify. An auditor can systematically go through the standard's requirements and check whether the contract satisfies each. A developer can use the same list pre-audit to self-check.

3. Levels. Tiers of assurance. A contract that passes "Basic" requirements is not as secure as one that passes "High Assurance" — and the standard defines what each level means. Buyers and users can compare contracts at a glance.

4. Process. How an audit should be conducted, what documentation is required, what claims an auditor can make. Process standards make audit reports comparable rather than each being its own format.

Different standards emphasize different purposes. SCSVS leans toward checklist and level. EthTrust leans toward process and certification claims. SWC focuses on vocabulary. The standards complement rather than compete.

The Major Standards in 2026

Five frameworks dominate the current landscape:

OWASP Smart Contract Security Verification Standard (SCSVS)

The OWASP Smart Contract Security project is the largest open-standards effort in this space. It includes multiple documents:

  • SCSVS (Smart Contract Security Verification Standard) — the core requirements framework
  • SCSTG (Smart Contract Security Testing Guide) — how to test the requirements
  • SCWE (Smart Contract Weakness Enumeration) — classification of common weaknesses
  • Smart Contract Top 10 — the most critical risk categories
  • SCS Checklist — practical actionable checklist

SCSVS is structured around three security levels:

  • Level 1 — Basic Security: minimum baseline. Appropriate for low-risk contracts with limited value.
  • Level 2 — Moderate Security: more rigorous. Appropriate for DeFi protocols, contracts handling significant value, contracts integrating with multiple counterparties.
  • Level 3 — High Assurance: highest bar. Appropriate for mission-critical contracts holding nine-figure value, governance contracts with significant authority, bridge contracts with large TVL.

The standard organizes requirements into categories labeled SCSVS-XXXXX:

  • SCSVS-ARCH — Secure architecture, design principles, threat modeling
  • SCSVS-CODE — Secure development, testing, deployment policies
  • SCSVS-GOV — Business logic and economic mechanism security
  • SCSVS-AUTH — Access control and authentication
  • SCSVS-COMM — Secure communication between contracts and external systems
  • SCSVS-CRYPTO — Cryptographic implementation
  • SCSVS-ORACLE — Arithmetic, logic, and oracle correctness
  • SCSVS-BRIDGE — Cross-chain state and data integrity
  • SCSVS-DEFI — DeFi-specific concerns (gas, MEV, financial-logic)
  • SCSVS-COMP — Component-specific guidelines

Each category contains numbered requirements at each level. For example, a Level 2 access control requirement might be "Verify that role changes require multi-step confirmation"; the same category at Level 3 might add "Verify that role changes have timelock delays appropriate to the protocol's TVL."

SCSVS is freely available under Creative Commons. The project emerged from CredShields Security Team's research while developing SolidityScan; the public version is now maintained by OWASP.

A useful framing: SCSVS Level 2 is approximately the standard a mature audit firm would already apply implicitly. Level 3 is what's expected of protocols handling nine-figure value. Level 1 is the floor that nothing in production should fall below.

EEA EthTrust Security Levels Specification

The Enterprise Ethereum Alliance's EthTrust specification takes a different approach — it focuses on audit-process certification rather than direct requirements on the contract.

Version 3 (published March 2025) defines three certification levels:

  • [S] Security Level S: Verified by automated checks. Tools have been run; their results have been reviewed; certain machine-detectable issues have been ruled out.
  • [M] Security Level M: Verified by manual audit. A human security reviewer has examined the contract and confirmed it does not have a defined set of vulnerabilities.
  • [Q] Security Level Q: Verified by full logic and documentation review. The reviewer has examined not just the code but also the contract's documentation, threat model, and intended behavior, and confirmed the implementation matches the documented intent.

The standard explicitly disclaims absolute security guarantees: "EEA EthTrust Certification means that at least a defined minimum set of checks has been performed on a smart contract. This does not mean the Tested Code definitely has no security vulnerabilities." This honest framing is itself a contribution — many "certifications" in the broader software security industry overstate what they guarantee.

EthTrust was developed by representatives from major audit firms (Diligence, OpenZeppelin, Hacken, CertiK) plus enterprise stakeholders (Banco Santander, Microsoft, EY). The enterprise focus distinguishes it from SCSVS's developer-centric orientation.

Smart Contract Weakness Classification (SWC)

The older but still widely-cited classification system for smart contract weaknesses. SWC predates the current OWASP and EEA efforts and provided early vocabulary for discussing specific bugs.

SWC entries (SWC-100 through SWC-136 in the most recent maintenance) are short, technical descriptions of specific weakness types:

  • SWC-100: Function Default Visibility
  • SWC-101: Integer Overflow and Underflow
  • SWC-107: Reentrancy
  • SWC-115: Authorization through tx.origin
  • SWC-116: Block values as a proxy for time
  • ...

Many audit reports still reference SWC numbers when describing findings. OWASP's SCWE is the modern successor that attempts to absorb and extend SWC; the transition is gradual.

For developers, the practical value of SWC is as a quick reference: "is this pattern documented as a known weakness?" The list isn't exhaustive (many newer DeFi-specific patterns don't have SWC numbers) but covers the foundational bug classes well.

EEA DeFi Risk Assessment Guidelines

Published in July 2024 by the EEA's DRAMA Working Group, these guidelines compile DeFi-specific risks alongside mitigation strategies. They cover concerns that go beyond smart contract bugs:

  • Economic risks (token design, incentive failures)
  • Counterparty risks (which other protocols you depend on)
  • Operational risks (multisig key management, upgrade processes)
  • Market risks (liquidity, volatility, oracle reliability)
  • Regulatory risks (depending on jurisdiction)

The guidelines fill a gap that pure code-focused standards leave open. A protocol can have perfectly secure code and still fail because of unsustainable economics, dependency on a compromised oracle, or other off-code factors. The DeFi Risk Assessment Guidelines extend the security framework into the protocol-design layer.

Industry-Specific Standards

Beyond the general frameworks, several industry-specific or niche standards have emerged:

  • MakerDAO's audit standards — internal but published; influential because Maker's standards are widely emulated
  • Compound's security best practices — similarly internal but published
  • Trail of Bits' Building Secure Smart Contracts — a curated guide that functions as an informal standard
  • ConsenSys Diligence's Smart Contract Best Practices — long-running reference, now maintained as historical material
  • Cosmos SDK security guidelines — for Cosmos-ecosystem chains (relevant for non-EVM platforms per Section 3.12.6)
  • Aleo, StarkWare, and other ecosystem-specific guides — covering platform-specific concerns

These are not "standards" in the formal sense but function as widely-followed conventions within their respective communities.

What Standards Don't Cover

The standards have known gaps. Honest framing requires noting them:

Economic and Game-Theoretic Bugs

SCSVS Level 3 and EthTrust [Q] both attempt to cover economic logic, but the granularity is limited. Bugs like the Euler exploit (Section 3.10.8) involved an inconsistency in invariant enforcement that the standards do address — but the standards don't fully cover MEV-amplified attacks, sophisticated incentive manipulation, or game-theoretic failure modes.

Standards-driven audits will catch many bugs that standards-free audits might miss; they will not catch novel economic attacks. Section 3.11 covers the architectural concerns where standards have weakest coverage.

Cross-Contract Composability

Standards generally address one contract at a time. Bugs that emerge from the interaction of multiple contracts — flash-loan-amplified manipulation across protocols, sandwich attacks that depend on multiple parties' behavior — are hard to specify as requirements on individual contracts. Section 3.11.2 covers this.

Off-Chain Components

A protocol includes more than its on-chain contracts: front-end interfaces, monitoring infrastructure, multisig key management, governance procedures, incident response plans. Standards like SCSVS cover the on-chain layer; the off-chain layer is the protocol's own discipline.

Specific Novel Patterns

Standards lag the field. A new attack pattern discovered in 2026 won't appear in standards until late 2026 or 2027 at the earliest. Standards-based audits catch known patterns; novel patterns require expert judgment.

Quality Beyond Security

Standards focus on security. Many factors that affect a protocol's outcomes — code quality, maintainability, gas efficiency, user experience — are outside the standards' scope or covered only lightly. A standards-compliant contract can still be hard to maintain, expensive to use, or confusing to integrate with.

How to Use Standards in Practice

For different roles, different uses of standards:

As a Developer

Standards are useful as pre-audit self-check. Before engaging an audit firm, run through SCSVS Level 2 requirements (or Level 3 if the protocol warrants) and verify each. Most of the requirements have automated tool support (Slither, MythX, etc.) that can check them.

This is genuinely valuable: catching the obvious issues internally before the audit means the audit can focus on more sophisticated concerns. Audit time on "the contract doesn't use SafeERC20" is audit time not spent on novel reentrancy patterns.

The pattern: standards establish the baseline; expert judgment goes beyond it. A protocol that hasn't met the baseline is not ready for the expert review.

As an Audit Buyer

When engaging an audit firm, ask what standards they apply. A firm using SCSVS or EthTrust as their checklist is providing a more comparable service than a firm using their own internal methodology.

The audit report should specify which standards were applied, which levels, and which requirements were verified versus not. This makes the audit comparable to other audits of similar protocols.

Common practice in 2026: top-tier firms apply multiple standards plus their own expertise. The standards are the floor; the firm's value-add is what they catch beyond the floor.

As an Audit Firm

Standards reduce the firm's discovery work — instead of figuring out what to check from scratch, the firm starts with a documented list. This is genuine efficiency: junior auditors can systematically apply the standard while senior auditors focus on novel concerns.

The firm's value proposition shifts from "we know what to look for" (the standard now publishes that) to "we know what to look for and we catch novel issues beyond the standard."

As a User or Integrator

Standards make protocol comparisons possible. A protocol claiming "Level 3 SCSVS compliance" or "EthTrust [Q] certification" has demonstrated meeting a specific bar. A protocol claiming "we have audits" without specifying what the audits checked has demonstrated only that they paid for audits.

For deciding which protocols to integrate with or use, standards-based claims are more informative than vague "fully audited" marketing.

As a Researcher or Educator

Standards are useful teaching material. The categories of SCSVS map to natural curriculum chapters. The SWC catalog provides specific bug-by-bug case studies. Standards-based learning produces structured knowledge rather than ad-hoc lore.

The Certification Question

A persistent question in the standards space: can a protocol be officially "certified" against these standards?

The honest answer in 2026: not in a regulatory or universally-recognized sense.

OWASP's position is explicit: "All such assurance assertions, trust marks, or certifications are not officially vetted, registered, or certified by OWASP." Anyone can claim SCSVS compliance; OWASP doesn't run a certifying body.

EEA's EthTrust is similar: any auditor can claim to apply the EthTrust specification and grant EthTrust certification. EEA doesn't accredit auditors.

This is intentional. Formal certification would require regulatory authority, ongoing maintenance, dispute resolution mechanisms, and other infrastructure that doesn't exist in the decentralized ecosystem. The standards work by establishing common vocabulary and expectations; the market enforces compliance through reputation.

The practical reality:

  • Reputable audit firms align with standards because their clients expect it
  • Protocols cite standards-compliance because it's a meaningful signal
  • Users trust standards-aligned audits more because the criteria are checkable
  • Bad actors can claim compliance falsely, but they can always do this with any quality claim

The trust comes from the auditor's reputation, the specificity of the certification claim, and the public verifiability of the requirements. None of this is the same as ISO certification or similar enterprise frameworks, but for the current state of the industry, it functions.

What's Changing in 2026

Several developments worth tracking:

Standards consolidation. SCSVS, EthTrust, and other efforts are increasingly cross-referenced. SCSVS now maps to SWC entries; EthTrust requirements correspond to specific SCSVS controls. The expectation is gradual consolidation, with one or two frameworks emerging as defaults.

Regulatory alignment. As regulatory frameworks for digital assets mature in various jurisdictions, regulators are looking at security standards as a basis for compliance requirements. The EU's MiCA framework, the U.S. SEC's developing guidance, and similar efforts in Singapore and the UAE may eventually formalize standards adoption.

Non-EVM coverage. Most current standards are EVM-focused. Move, Solana, and Cairo communities are developing or considering parallel standards for their platforms. Cross-platform standards are an active area but not yet mature.

Cross-chain bridge standards. Following the bridge case studies (Section 3.10.4-7), specific standards for bridge security are an emerging focus. The SCSVS-BRIDGE category and EEA's Cross-Chain Security Guidelines Version 1.0 are early examples; deeper standards may follow.

Integration with tooling. Standards are increasingly automatable. Slither, MythX, and other static analysis tools are adding direct checks for specific SCSVS requirements. The future is "standards-aware tooling" rather than tools and standards being separate concerns.

Continuous compliance. Rather than one-time audits checking standards compliance, continuous monitoring against standards (especially relevant for deployed contracts that may degrade as ecosystem changes) is emerging. Tools that re-check compliance against new standards versions or new attack patterns are starting to appear.

Practical Checklist

For a protocol team adopting standards:

  • Standards have been selected (typically SCSVS plus EthTrust certification) and documented
  • Standards level (e.g., SCSVS Level 2 vs. 3) is chosen based on protocol risk profile
  • Internal pre-audit checklist runs through the selected standards
  • Audit firms are asked which standards they apply
  • Audit reports cite specific requirements verified
  • Public security posture documentation references the standards applied
  • The team is aware of standards' known gaps (economic logic, cross-chain, novel patterns)

For an audit firm:

  • Standards are explicit in the firm's methodology
  • Audit reports cite specific requirements from named standards
  • Findings beyond standards' coverage are clearly noted as such
  • Firm expertise is positioned as standards-floor plus novel-issue discovery
  • Continued participation in standards development is part of the firm's investment

For a user evaluating protocol security claims:

  • "Audited" without specification is treated as unsupported
  • Claims like "SCSVS Level 2 compliant" or "EthTrust [Q] certified" are verified against actual audit reports
  • Standards' inherent limitations are understood (no certification is a guarantee)
  • Multiple signals (standards compliance, audit firm reputation, track record, bug bounty payouts) are combined for an overall assessment

Cross-References

  • Audit practices — Section 3.9 covers the audit discipline that standards formalize
  • Common vulnerabilities — Section 3.8 maps to many SCSVS/SWC categories
  • Defensive patterns — Section 3.7 covers patterns standards require
  • Decentralized auditing — Section 3.12.3 covers the audit market that delivers standards-aligned reviews
  • AI in security — Section 3.12.2 covers tooling increasingly being aligned with standards
  • Formal verification — Section 3.12.1 covers techniques that complement standards-based review
  • OWASP SCSVS — https://scs.owasp.org/SCSVS/
  • OWASP SCS Project — https://github.com/OWASP/owasp-scs
  • EEA EthTrust — https://entethalliance.org/specs/ethtrust-sl/
  • EEA DeFi Risk Assessment Guidelines — https://entethalliance.org/specs/defi-risks/
  • Smart Contract Weakness Classification (SWC) — https://swcregistry.io
  • Trail of Bits Building Secure Smart Contracts — https://github.com/crytic/building-secure-contracts