Study CBSE by layer, not by topic list. For every attack you review, write down: (1) which layer it exploits (smart contract code, cryptography, consensus, economic incentives, or governance), (2) what capability or position the attacker must have, and (3) which control targets that specific capability. Practice this mapping with written scenarios, compare adjacent concepts such as reentrancy versus oracle manipulation or key loss versus key compromise, and use the self-check rubric below to confirm you can distinguish layers before moving on.
Why smart contract bugs and economic exploits are different problems
A smart contract vulnerability is a flaw in code logic anyone can call; an economic exploit abuses market mechanics and external data without breaking the code. Identifying which layer failed determines which defense applies.
A code-layer flaw, such as reentrancy or an unchecked external call, exists in the deployed bytecode. Anyone who can send a transaction can trigger it, and the fix is a code change: checks-effects-interactions ordering, reentrancy guards, or withdrawal patterns. When you study these, anchor each one to the exact code pattern that permits it rather than to a memorable incident name.
An economic exploit, by contrast, leaves the contract functioning exactly as written. The attacker arranges market conditions, for example by borrowing large temporary positions, so that executing the honest code produces a dishonest outcome. Defenses live outside the code: price-feed design, position limits, pausable parameters, and monitoring. If you attribute an economic exploit to a code bug, you will select the wrong control in scenario questions.
- Code layer: the flaw is in logic the contract itself executes.
- Economic layer: the code behaves as designed; the environment around it was manipulated.
- Defense test: ask whether a code audit alone would have prevented the outcome.
Scenario: diagnosing a drained lending pool correctly
When a lending pool empties in one transaction block, trace the price source before naming a vulnerability. The plausible mistake is blaming reentrancy; the better diagnosis is often oracle manipulation via a flash-borrowed position.
Scenario: a protocol prices a collateral asset from a thin decentralized exchange pool. An attacker flash-borrows a huge amount, swaps it to push the spot price, borrows against the inflated collateral value, and walks away, repaying the flash loan in the same transaction. The plausible mistake is writing 'reentrancy' in your analysis because funds drained in one transaction. Nothing was re-entered; every call behaved as coded.
The better decision is to ask what data the contract trusted and who could move it. The trusted input, the DEX spot price, was manipulable by anyone with temporary capital. This distinction matters because the remediation differs entirely: a reentrancy guard fixes nothing here, while a manipulation-resistant price source, such as a time-weighted average or an oracle with documented aggregation, addresses the actual capability the attacker used. Practice narrating that causal chain in two or three sentences.
Threat modeling a DApp: actors, assets, and entry points
A blockchain threat model names who can act (actors), what they want (assets), and how they reach it (entry points), then assumes adversarial users and public code by default, unlike traditional models that can trust a perimeter.
Blockchain systems remove several traditional assumptions. There is no network perimeter to hide behind, transactions are publicly constructed by pseudonymous users, and deployed code is visible. Your threat model must therefore start from capability: any address can call any public function, and any participant can observe every state change. Compare this with a traditional web threat model where authentication and network segmentation reduce who can even attempt an attack.
A practical method: list every entry point (public functions, admin functions, off-chain components that feed data on-chain), every asset (user funds, minting rights, upgrade authority), and every actor class (ordinary users, token holders, the deployer, miners or validators, external data sources). Then pair each asset with the actor capable of reaching it. Exercise this with a paper scenario rather than a live system, so you can explore worst cases safely and compare your actor list with a peer's to find missing capability assumptions.
- Entry points include admin keys and oracles, not just user-facing functions.
- Assets include authority to upgrade, pause, or mint, not only token balances.
- Validator and miner behavior belongs in the model; they are actors with capabilities.
Key loss versus key compromise: two failures, different controls
Key loss means the key is unavailable, so assets become unreachable; key compromise means an unauthorized party has it, so assets become stealable. Availability controls address the first; confidentiality and authorization controls address the second.
Scenario: a treasury uses a single hot wallet for everything, and the team proposes 'backups everywhere' as the fix after a scare. The plausible mistake is treating all key risk as one risk. Storing the same key in many places reduces loss risk but multiplies compromise surface. The better decision separates the two failure modes explicitly and chooses different controls for each.
Against loss, plan recovery: distributed key shares or a multi-signature arrangement so no single unavailable share blocks access. Against compromise, limit exposure: keep signing keys off always-connected machines, separate hot operational keys from cold reserve keys, and require multiple independent signatures for large movements so one stolen key is insufficient. Writing both failure modes on paper before choosing controls is the transferable skill; the same separation reappears in custody, multisig design, and enterprise key-management questions.
What a majority-of-consensus-power attacker can and cannot do
An attacker controlling the majority of consensus power can reorder or exclude recent transactions and double-spend their own funds, but cannot forge signatures, invent balances, or alter rules that other participants reject.
Study consensus attacks as a statement about what finality means. Consensus decides ordering and inclusion of valid transactions; it does not validate a transaction that fails signature or balance checks. So a majority attacker can censor your transactions, reorganize recent blocks to reverse their own payments, and orphan competing blocks. Those are the capabilities. Everything outside them, such as spending funds they do not hold, still fails basic validity rules.
The practical consequence for security analysis is that the cost of majority power is the effective security budget of the chain, and defenses differ by context. A merchant accepting payments should wait for confirmation depth proportional to attack cost; a protocol deployed on a chain should consider whether its security assumptions survive reorganizations. In your notes, keep a two-column habit: what the attacker achieves, and what still blocks them. This prevents the common overstatement that majority control equals total control of the ledger.
| Attack class | Layer | Attacker capability required | Primary defense direction | Does NOT let the attacker |
|---|---|---|---|---|
| Reentrancy | Smart contract code | Ability to call the vulnerable function | Checks-effects-interactions, reentrancy guards | Forge signatures or balances |
| Oracle price manipulation | External data / economics | Capital to move the price source | Manipulation-resistant price feeds | Alter contract code |
| Majority consensus attack | Consensus | Majority of consensus power | Confirmation depth, high attack cost | Spend others' funds or break cryptography |
| Key compromise | Key management | Access to the secret key | Isolation, multi-signature, cold storage | Reroute transactions to a new address without signing |
| Malicious upgrade or admin action | Governance | Upgrade authority or voting majority | Timelocks, multisig governance, transparent process | Bypass the upgrade mechanism itself |
DeFi-specific risks: composability means inherited risk
In DeFi, protocols call each other, so each integration imports every dependency's assumptions: its price feed, its admin keys, its upgrade path. Risk assessment must therefore cover the whole dependency chain, not one contract.
A lending market, an automated market maker, and a yield vault each have their own threat model, but composability means your protocol's safety can depend on theirs. If an upstream pool's price can be skewed, every downstream consumer inherits that weakness regardless of its own code quality. When studying DeFi security, practice tracing the chain: what does my protocol read, who controls that source, and what happens if it reports a wrong value?
Governance risk compounds this. An upgradeable dependency whose admin key can change logic is a standing capability someone holds; a timelock and multi-signature control turn a silent change into a visible, delayed one. Compare two paper protocols side by side, one immutable and one upgradeable behind governance, and list for each who can change what and how you would detect it. The comparison builds the judgment that exam scenarios reward: matching a risk to the mechanism that actually contains it.
Enterprise and permissioned DLT: where the trust model flips
Permissioned networks replace anonymous economic incentives with known, accountable participants, so the dominant risks shift toward identity management, access governance, and off-chain process, rather than sybil resistance.
In a public network, anyone may join and security rests on incentives and cost. In a permissioned enterprise network, membership is granted, participants are identifiable organizations, and consensus may assume a bounded set of known validators. That changes the threat model: collusion among known members, compromised member credentials, and weak onboarding or offboarding procedures become primary concerns, while needing to defend against unlimited anonymous participants largely disappears.
Governance questions therefore dominate this domain: who admits members, who can deploy chaincode or smart contracts, how are rule changes approved, and how is disputes resolution recorded? Practice by contrasting a public chain scenario with a consortium scenario on the same facts, and observe which risks swap places. Self-check: if you can explain why sybil resistance matters in one setting and identity vetting in the other, this layer is consolidated. If both answers sound identical, revisit the membership assumption first.
- Membership is a control surface: admission, revocation, and credential lifecycle.
- Known validators change collusion analysis from economic to contractual.
- Off-chain process (sign-off, audit trails) is part of the security design.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.