Threat modeling is a structured exercise in adversarial thinking. You ask four questions in sequence: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job? The answers produce a living document that guides every downstream security decision, from architecture choices to audit scope to incident response playbooks.
In traditional software engineering, threat modeling is well-established. In smart contract development, it remains underused. Teams reach for audits as their primary security mechanism and treat threat modeling, if they think about it at all, as something that happens inside an auditor’s head during the engagement. This is backwards. An audit is a point-in-time inspection of code that already exists. A threat model is a forward-looking analysis that prevents bad code from being written in the first place.
What Threat Modeling Is — and Is Not
Threat modeling is not a vulnerability scanner. It does not read your Solidity and flag unchecked return values. It is a manual, collaborative reasoning process that produces a shared understanding of the system’s security posture before a single line of code is finalized.
The output of a threat model is not a pass/fail verdict. It is a prioritized catalog of threats, each linked to a component, a potential attacker, and a proposed countermeasure. That catalog becomes the north star for every security decision made during the project’s lifetime.
Threat modeling is also not a one-time event. The first session happens before architecture is finalized. A second pass happens when the design changes significantly. A third pass informs the audit scope document. After deployment, the model is updated as the protocol evolves, new integrations are added, or the threat landscape shifts.
The most important property of a threat model is that it forces explicit decisions. When a team decides not to mitigate a particular threat, that decision is recorded, reasoned, and owned. Nothing is overlooked by accident.
Why Before the First Line of Code
The cost of fixing a security problem grows exponentially as a project matures. A design flaw caught in a whiteboard session costs an afternoon of discussion. The same flaw caught during audit costs a redesign, a re-audit, and a delayed launch. Caught after deployment, it costs user funds, protocol reputation, and potentially the project’s existence.
Smart contracts intensify this dynamic because they are immutable by default. A deployed contract cannot be patched the way a web server can. Upgrade mechanisms exist, but they introduce their own attack surface. The honest reality is that the architecture you commit to before writing code is largely the architecture you are stuck with.
Threat modeling before development shapes architecture in ways that audits cannot. When you enumerate trust boundaries early, you discover that a particular oracle integration requires assumptions that your architecture does not support. You fix it by redesigning the data flow. If you discover this during an audit, you face a choice between a risky late-stage redesign and accepting a known weakness.
Early threat modeling also aligns the team. Developers, protocol designers, and business stakeholders often have different mental models of who the users are and what the adversaries want. A structured threat modeling session surfaces these misalignments before they become embedded in the codebase.
The STRIDE Framework Applied to DeFi Protocols
STRIDE is a threat categorization framework originally developed for enterprise software. Each letter names a threat category. Applied to DeFi, each category maps cleanly onto known attack patterns.
Spoofing
Spoofing means an attacker impersonates a legitimate entity. In DeFi, this surfaces in several ways. A contract might spoof the address of a trusted oracle by deploying to a predictable address using CREATE2. A governance proposal might spoof a benign action by hiding malicious calldata behind a human-readable description. A token contract might spoof a reputable token by registering a similar name and symbol.
Countermeasures focus on verifying identity at every trust boundary: allowlisting oracle addresses, verifying contract bytecode hashes rather than addresses alone, and requiring human review of decoded calldata in governance proposals.
Tampering
Tampering means unauthorized modification of data. In smart contracts, storage is public and persistent, making tampered state immediately observable but also difficult to reverse. Reentrancy attacks are a form of tampering: an attacker manipulates the protocol’s internal accounting by re-entering before state is finalized. Price oracle manipulation is another: an attacker tampers with the price feed the protocol depends on, using flash loans to move market prices within a single transaction.
Countermeasures include strict checks-effects-interactions ordering, reentrancy guards, time-weighted average prices instead of spot prices, and circuit breakers that halt operations when prices move beyond expected bounds.
Repudiation
Repudiation means an attacker performs an action and then denies having done it. In smart contracts, the blockchain’s immutable ledger makes true repudiation impossible at the transaction level — every transaction is attributable to a signing key. However, repudiation threats emerge at the protocol logic level. A multisig signer might claim they did not understand what they were signing. A governance voter might claim a proposal description was misleading. An admin key holder might claim a privileged action was taken under duress.
Countermeasures focus on making intent explicit and auditable: detailed event emission for every privileged action, timelock mechanisms that give the community time to observe and react, and governance proposal standards that require decoded calldata alongside human-readable descriptions.
Information Disclosure
Information disclosure means sensitive data is exposed to unauthorized parties. Solidity developers sometimes make the mistake of treating private state variables as secret. They are not. All contract storage is readable by anyone who queries the chain directly, regardless of visibility modifiers. Sensitive data — private keys, unrevealed game states, front-running-sensitive order flow — cannot be stored in contract state without cryptographic protection.
Countermeasures include commit-reveal schemes for sensitive inputs, off-chain storage for data that must remain private, and explicit documentation of what information is intentionally public so that future developers do not accidentally build privacy assumptions on top of inherently transparent storage.
Denial of Service
Denial of service in DeFi takes forms that differ from traditional networking attacks. Gas griefing is a common pattern: an attacker causes a critical transaction to consume more gas than the block limit allows, preventing it from executing. Unbounded loops are a classic root cause — if a protocol iterates over an array of user positions and an attacker can inflate that array, they can brick liquidations. Another form is a dust attack: an attacker sends tiny amounts of a token to a contract to corrupt accounting or to cause integer precision errors.
Countermeasures include pull-payment patterns instead of push payments, pagination for any operation that iterates over user-controlled arrays, and minimum deposit thresholds that make dust attacks economically unattractive.
Elevation of Privilege
Elevation of privilege means gaining capabilities beyond what is intended. In smart contract systems, this often appears as access control vulnerabilities: a function intended for admins is callable by anyone because a modifier is missing. It also appears in more subtle forms, such as a governance attack where an attacker accumulates sufficient voting power to pass proposals that grant themselves privileged access to protocol funds.
Countermeasures include thorough access control audits, timelocks on all privileged operations, governance quorum and delay requirements, and separation of roles so that no single key can perform every sensitive operation.
Identifying Trust Boundaries
A trust boundary is a line across which data or control passes between components with different trust levels. Every time your protocol calls an external contract, reads from an oracle, accepts user input, or executes a governance decision, it crosses a trust boundary.
Mapping trust boundaries is the most important structural exercise in threat modeling. The process is straightforward: draw every component in your system, then draw every arrow representing a data or control flow between components. Each arrow is a candidate trust boundary. Ask, for each arrow: what assumptions does the receiving component make about the data coming in? What happens if those assumptions are violated?
In a typical DeFi lending protocol, the key trust boundaries include:
User to Protocol. Users submit transactions with arbitrary calldata. The protocol trusts that the user’s inputs are well-formed but must not trust that they are honest. Any input that affects internal accounting, determines a liquidation threshold, or influences a price must be treated as potentially adversarial.
Protocol to Oracle. The protocol reads a price from an external oracle. The protocol trusts that this price reflects fair market value. The threat is that an attacker can manipulate the price, either by exploiting the oracle’s own vulnerabilities or by moving the underlying market. The trust boundary here requires the protocol to enforce freshness checks, circuit breakers, and secondary price validation.
Protocol to External Token Contracts. When a lending protocol accepts a new collateral token, it crosses a trust boundary with that token’s contract. The token might be reentrant, might charge transfer fees, might be upgradeable, or might have a blacklist function that could brick protocol accounting. Every token integration is a new trust boundary that requires explicit analysis.
Governance to Protocol. Governance decisions can modify protocol parameters, upgrade implementation contracts, or drain treasury funds. The governance system is a trust boundary: the protocol trusts that governance decisions represent the will of legitimate stakeholders. Attackers target this boundary through vote buying, flash loan governance attacks, and social engineering.
Admin Keys to Protocol. Admin keys are a concentrated trust boundary. A single compromised key might be able to pause the protocol, change fee recipients, or upgrade contracts. The threat model must enumerate exactly what each privileged role can do and what the blast radius of a compromise would be.
Enumerating Threat Actors
A threat model without specific threat actors is too abstract to be useful. Different attackers have different capabilities, motivations, and constraints. Designing defenses requires knowing who you are defending against.
Ordinary Users
Not all threats come from sophisticated attackers. Ordinary users make mistakes: they send funds to the wrong address, they interact with a contract in an unexpected sequence, they submit transactions that revert and blame the protocol. While these are not malicious attacks, they represent a category of threat to user funds that the protocol is responsible for mitigating through good design. Clear error messages, input validation, and safe defaults all address this threat actor.
MEV Searchers
Maximal Extractable Value searchers are sophisticated, well-resourced actors who monitor the mempool and blockchain state for profitable opportunities. They are not necessarily malicious in the traditional sense — they operate within the rules of the protocol — but their presence is a threat to specific security properties. Sandwiching a user’s swap between two transactions, front-running a liquidation, or back-running a large trade to arbitrage a resulting price impact are all MEV extraction strategies that affect user outcomes.
MEV searchers have capabilities that ordinary users do not: they run custom infrastructure, they can submit bundles to block builders, they can simulate transactions with high speed, and they can execute multi-transaction strategies atomically. Designs that assume transactions execute in isolation, without considering the surrounding block context, are vulnerable to MEV extraction.
Countermeasures include using commit-reveal schemes for sensitive operations, integrating with private transaction relays, designing slippage tolerance carefully, and being explicit about which protocol behaviors are intentionally MEV-resistant and which are not.
Governance Attackers
Governance attackers seek to control protocol decision-making. Their strategies range from legitimate to clearly malicious. A large token holder might use their voting power to pass proposals that benefit themselves at the expense of other users. An attacker might accumulate governance tokens through flash loans to pass a malicious proposal in a single transaction. A coordinated group might engage in vote buying, compensating token holders to vote a particular way.
The threat model for governance must consider the minimum cost of a successful governance attack, the delay between proposal and execution, the range of actions that governance can authorize, and the existence of emergency mechanisms that bypass governance.
Compromised Admin Keys
Admin keys represent a special category of threat actor: the legitimate holder of a privileged key who has been compromised. This might be a private key stolen from a developer’s machine, a seed phrase exposed in a backup, or a team member who turns malicious. The threat model must assume that any single key can be compromised and reason about the consequences.
A compromised admin key that can upgrade implementation contracts can drain all protocol funds instantly. A compromised key that can only pause the protocol causes disruption but not theft. The principle of least privilege applied to admin roles directly reduces the blast radius of a key compromise.
Countermeasures include multisig requirements for all privileged operations, hardware security modules for key storage, timelocks that give the community time to observe and react to suspicious actions, and explicit off-boarding procedures when team members leave the project.
Protocol Integrators
Protocols that integrate with yours are a frequently overlooked threat actor category. A protocol that holds a large position in your system, controlled by its own governance, can behave in ways that destabilize your protocol. If an integrated protocol is upgraded in a breaking way, if its governance makes decisions that conflict with your safety assumptions, or if it is itself exploited and becomes insolvent, the effects propagate across the trust boundary into your system. This is sometimes called a composability risk.
Mapping Attack Surfaces to Protocol Components
An attack surface is the sum of all points where an attacker can attempt to enter or extract data from a system. In smart contract protocols, attack surfaces map directly to components.
Entry points are all externally callable functions. Each public and external function is a potential attack surface. Functions that accept user input are higher risk than view functions, but even read functions can be abused if they affect other systems through side effects or if they leak information useful to an attacker.
Storage layout is an attack surface for upgrade patterns that use delegatecall. A storage collision between a proxy and its implementation can overwrite critical variables. This is not a theoretical risk — it has caused significant losses in production systems.
Dependencies represent the aggregate attack surface of everything your protocol relies on. If your protocol uses three external libraries, two oracles, and four integrated protocols, the attack surface of your protocol includes all of their attack surfaces in the context of how your protocol interacts with them.
Economic mechanisms are an attack surface unique to DeFi. The mathematical relationships between protocol parameters — collateral ratios, interest rate curves, liquidation penalties — can be exploited if they produce perverse incentives under adversarial conditions. A liquidation mechanism that becomes unprofitable to execute under certain market conditions creates a denial of service vulnerability in the protocol’s solvency mechanism.
Governance mechanisms are an attack surface for protocol parameters. Any value that governance can change is a potential attack surface: fee levels, supported collateral types, oracle sources, access control lists, and upgrade authority.
Prioritizing Threats
Not all threats deserve equal attention. Prioritization focuses limited security resources where they have the most impact.
The standard approach scores each threat on two dimensions: likelihood and impact. Likelihood considers how difficult the attack is to execute, what resources or capabilities the attacker needs, and whether the attack requires specific market conditions or timing. Impact considers the maximum loss of funds, the reversibility of the damage, the number of users affected, and the reputational consequences for the protocol.
A threat with high likelihood and high impact is a critical risk that must be mitigated before deployment. A threat with low likelihood and low impact is acceptable risk that can be documented and monitored. The interesting cases are high-impact, low-likelihood threats — catastrophic but improbable events like governance takeovers — which typically justify structural mitigations like timelocks and multisig requirements even when the probability seems low.
For each threat in the catalog, the threat model records the threat description, the affected component, the threat actor, the likelihood score, the impact score, the overall risk rating, and the proposed countermeasure or the explicit decision to accept the risk.
A practical scoring approach for DeFi protocols:
| Threat | Component | Actor | Likelihood | Impact | Risk | Countermeasure |
|---|---|---|---|---|---|---|
| Flash loan governance attack | Governance | Token holder | Medium | Critical | High | Snapshot-based voting, no flash loan voting |
| Oracle price manipulation | Price feed | MEV searcher | Medium | Critical | High | TWAP, circuit breakers |
| Reentrancy in withdrawal | Vault | Malicious contract | Low | High | Medium | CEI pattern, reentrancy guard |
| Admin key compromise | Access control | External attacker | Low | Critical | High | Multisig, timelock |
| Unbounded loop in liquidation | Liquidation engine | Dust attacker | Medium | Medium | Medium | Pagination, minimum position size |
How Threat Models Inform the Audit Scope Document
An audit scope document tells auditors where to focus their attention. A well-constructed scope document produces a more effective audit. A poor scope document — typically just a list of files and a commit hash — wastes auditor time on low-risk components and leaves high-risk components under-examined.
The threat model is the foundation of a good scope document. After threat modeling, you know which components carry the most risk, which trust boundaries require careful examination, and which threat categories are most relevant to your protocol’s design.
From the threat model, the scope document should specify:
High-priority components. The files and contracts that the threat model identified as carrying concentrated risk — typically the accounting core, the access control system, and any component that crosses a high-risk trust boundary — should be flagged for deeper examination.
Specific threat categories. If the threat model identified oracle manipulation as a critical risk, the scope document should explicitly ask auditors to examine oracle integration patterns. If governance attacks are a priority threat, auditors should examine the governance execution path in detail.
Known assumptions to validate. The threat model will have identified assumptions that the protocol makes about external components — that the oracle is fresh, that integrated tokens are non-reentrant, that governance has sufficient delay. The scope document should ask auditors to validate or challenge these assumptions.
Out-of-scope items with reasoning. Equally important is being explicit about what is not in scope and why. If a particular integration is excluded because it was separately audited, or because the protocol accepts the associated risk, that should be stated. This prevents auditors from spending time on areas the team has already analyzed and accepted.
Economic security questions. Auditors with financial modeling expertise should be directed to examine the protocol’s economic mechanisms under adversarial conditions. The threat model’s economic attack scenarios become specific questions in the scope document.
The result is an audit that is targeted, efficient, and aligned with the protocol’s actual risk profile rather than a generic survey of the codebase.
Running a Threat Modeling Session with a Protocol Team
Threat modeling is a collaborative activity. A session that involves only the security team produces a narrower model than one that includes protocol designers, developers, and people who understand the economic mechanisms. Here is how to run an effective session.
Preparation
Before the session, collect all available documentation: the protocol specification, architecture diagrams, any existing design documents, and a list of external dependencies. If architecture diagrams do not exist, their creation is the first deliverable of the session. You cannot reason about trust boundaries without a map of the system.
Assign a facilitator whose job is to keep the session structured and moving. The facilitator is not the person doing all the threat identification — they are drawing out contributions from everyone in the room. Assign a scribe to capture every threat identified, even ones that seem minor or speculative. The threat catalog is refined after the session; nothing should be dismissed in real time.
Step One: Decompose the System
Start by building or reviewing the system decomposition. Map every component, every data store, every external dependency, and every user-facing entry point. Draw the trust boundaries. This step takes longer than teams expect, because building a shared mental model of the system surfaces misalignments between what different team members think the protocol does.
Ask each person in the room to describe the system in one sentence from the perspective of each user role. Differences in these descriptions reveal assumptions that need to be made explicit.
Step Two: Enumerate Threats Using STRIDE
Work through STRIDE systematically. For each component and each trust boundary in the diagram, ask what spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege threats exist.
Encourage quantity over quality at this stage. The goal is to generate a comprehensive list, not to immediately evaluate the feasibility of each threat. Wild or speculative threats sometimes point to real vulnerabilities when examined carefully. A threat that the team immediately dismisses as “too expensive” might become viable as the protocol’s TVL grows.
For DeFi protocols, supplement STRIDE with economic threat brainstorming. Ask: what happens if the largest possible position is liquidated simultaneously? What happens if an attacker can borrow the maximum amount of governance tokens for one block? What happens if the oracle reports a price two orders of magnitude outside the normal range?
Step Three: Prioritize
After the enumeration phase, score each threat on likelihood and impact. Do this as a group, using discussion to surface disagreements. Disagreements about likelihood or impact usually reflect differences in assumptions about attacker capabilities or protocol usage patterns. Making these disagreements explicit is itself a valuable output.
Focus the group’s attention on threats that score high on both dimensions. For each high-priority threat, identify a concrete countermeasure or make an explicit decision to accept the risk with documented reasoning.
Step Four: Document and Assign
Every threat in the catalog should have an owner — a person responsible for either implementing the countermeasure or formally accepting the risk. Without ownership, threat model outputs have a tendency to remain in a document and never influence actual development decisions.
The threat model document should be version-controlled alongside the codebase. When the protocol changes, the relevant section of the threat model is updated. When an audit finding corresponds to a threat that was not captured in the model, that is a gap to be analyzed and addressed in the next session.
Step Five: Validate After Development
Once development is complete and before the audit begins, reconvene the threat modeling session for a shorter validation pass. Review each threat and its proposed countermeasure. Verify that the countermeasure was implemented. Look for new threats introduced by implementation decisions that were not captured in the original design. This validation session also finalizes the audit scope document based on the current state of the threat model.
Common Failure Modes
Threat modeling sessions fail in predictable ways. Recognizing these patterns helps avoid them.
Optimism bias. Teams consistently underestimate attacker motivation and capability. If a threat requires an attacker to have ten million dollars in capital, the team tends to discount it. But DeFi attackers have access to flash loans that make large capital requirements temporarily achievable, and sophisticated actors with large balance sheets are a real threat to large protocols. A useful corrective is to assume the attacker is as well-resourced as the protocol’s TVL would justify.
Scope too narrow. Teams focus on the code they wrote and ignore external dependencies. The attack surface of your oracle provider is part of your attack surface. The attack surface of every token you accept as collateral is part of your attack surface. Every external contract your protocol calls is a potential threat actor.
No economic threat analysis. Standard STRIDE analysis is designed for information systems. DeFi protocols are financial systems, and their most distinctive vulnerabilities are economic in nature. A threat model that does not reason about incentives, market conditions, and capital efficiency under adversarial conditions is incomplete.
Threat model as checkbox. The most common failure mode is running a threat modeling session to satisfy a process requirement, then filing the output document and never consulting it again. A threat model that does not influence architecture, development, and audit scope has no security value. The document should be referenced at every significant design decision and kept current as the protocol evolves.
Closing Thoughts
Security in smart contract development is a design property, not a feature that can be added after the fact. Threat modeling is the discipline that makes this concrete: it gives teams a structured method for reasoning about adversaries before any code is written, a common vocabulary for discussing risk across technical and non-technical stakeholders, and a living document that keeps security concerns visible throughout the project lifecycle.
The protocols that have suffered the largest losses were not, for the most part, attacked in ways that were unforeseeable. The attack patterns were known. The relevant vulnerabilities had been publicly documented. What failed was not the state of knowledge in the field but the translation of that knowledge into the specific design decisions made by a specific team building a specific protocol.
Threat modeling is the bridge between general security knowledge and the particular decisions that determine whether a protocol is secure. It belongs at the beginning of every project, not at the end.