Threat modeling is a proactive security practice where development teams systematically identify potential attack vectors, trust boundaries, and adversarial scenarios before writing code. In smart contract development, threat modeling is especially critical because deployed contracts are immutable and directly control financial assets—making post-deployment fixes extremely costly or impossible.

Why threat modeling matters in Web3

Traditional software can be patched after deployment. Smart contracts cannot. This asymmetry makes pre-deployment analysis essential:

• Immutability: Once deployed, vulnerabilities cannot be patched without complex migration strategies
• Transparent code: Attackers can read your source code and plan exploits
• High-value targets: Contracts often hold millions in TVL, creating strong adversarial incentives
• Composability risks: Your contract interacts with other protocols that may behave unexpectedly

The threat modeling process

1. Define the system

Document the protocol's architecture, trust assumptions, and asset flows:

• What assets does the contract hold or manage?
• Who are the privileged actors (admin, governance, keepers)?
• What external dependencies exist (oracles, other protocols)?
• What are the intended state transitions?

2. Identify threats

For each component and interaction, enumerate potential attack vectors:

• Can an attacker manipulate inputs to extract value?
• What happens if an external dependency fails or is compromised?
• Are there economic incentives for malicious behavior?
• Can privileged roles be abused?

3. Evaluate and prioritize

Score each threat by likelihood and impact:

4. Define mitigations

For each prioritized threat, specify concrete defensive measures:

• Code-level protections (access control, reentrancy guards)
• Architectural changes (separating custody from logic)
• Operational controls (timelocks, multisigs)
• Monitoring and alerting (circuit breakers)

STRIDE for smart contracts

The STRIDE framework, originally developed by Microsoft, adapts well to blockchain-specific threats:

• Spoofing: tx.origin vs msg.sender confusion
• Tampering: Oracle manipulation via flash loans
• Repudiation: Missing event emissions for critical state changes
• Information Disclosure: Exposing private data on-chain
• Denial of Service: Unbounded loops, gas griefing
• Elevation of Privilege: Bypassing access controls

When to perform threat modeling

Threat modeling should occur at multiple stages:

1. Design phase: Before any Solidity is written—define trust assumptions and invariants
2. Pre-audit: Before engaging auditors—helps define audit scope and focus areas
3. Post-upgrade: When protocol logic changes—reassess threats against new functionality
4. Post-incident: After exploits in similar protocols—update threat models with new attack vectors

Common mistakes

• Skipping the design phase: Jumping straight to code and relying solely on post-implementation audits
• Ignoring economic threats: Focusing only on code-level bugs while missing tokenomics and incentive flaws
• Static threat models: Creating a threat model once and never updating it as the protocol evolves
• Overlooking composability: Not modeling how interactions with external protocols create emergent risks

Threat modeling is the foundation of a defense-in-depth security strategy. By identifying threats early, teams can architect solutions rather than patch symptoms.