Security, Risks, and Governance in Crypto Systems

1. Framing Security and Governance in Crypto Systems

In this module you connect what you know about DeFi primitives and game theory to real-world risks and governance in crypto systems.

Goal: By the end, you should be able to:

• Distinguish technical vulnerabilities from economic exploits.
• Explain how governance tokens and voting shape protocol evolution.
• Describe what forks are and why communities choose to fork.

Big Picture

Crypto systems combine:

• Code (smart contracts, consensus protocols)
• Markets (tokens, incentives, arbitrage)
• Communities (governance, social consensus)

Security problems can arise at each layer:

1. Protocol-level security (consensus, base layer, core smart contracts)
2. Application-level security (dApps built on top of protocols)
3. Economic security (incentives, MEV, governance capture)
4. Governance security (who decides upgrades, how conflicts are resolved)

You will see that not all losses are caused by “bugs”. Many are caused by rational actors exploiting economic design flaws.

2. Protocol-Level vs Application-Level Security

Think of crypto systems as a stack:

Layer 1 – Protocol-Level Security

• Includes: consensus mechanism (e.g., Ethereum proof-of-stake), base execution environment (EVM), core token contracts, validator sets.
• Typical risks:
• Consensus attacks (e.g., 51% or >2/3 attacks on smaller PoS/PoW chains)
• Finality failures (conflicting finalized blocks if consensus fails)
• Randomness manipulation (for protocols relying on chain randomness)
• Bridge security (often treated as protocol-level because bridges connect entire ecosystems)

Layer 2 – Application-Level Security

• Includes: DeFi protocols (DEXes, lending pools, yield aggregators), NFT marketplaces, derivatives platforms.
• Typical risks:
• Smart contract bugs (re-entrancy, integer overflows/underflows in older code, access control mistakes)
• Logic errors (wrong pricing formulas, incorrect collateral checks)
• Oracle failures (manipulated price feeds)

Visual Description

Imagine a three-layer diagram:

• Bottom: Blockchain & consensus (Ethereum, Solana, etc.)
• Middle: Core DeFi protocols (Uniswap, Aave, Curve)
• Top: Front-ends & aggregators (wallet UIs, dashboards, bots)

If the bottom layer fails, everything above is at risk. If a top dApp fails, the base chain can still be secure.

Key idea: Protocol-level failures are often systemic, while application-level failures are often local to a specific dApp or protocol.

3. Real-World Examples: Technical Vulnerabilities

Here are concrete examples to anchor the distinction.

Example A – Protocol-Level Risk: Bridge Exploits

• Cross-chain bridges (e.g., those connecting Ethereum, BNB Chain, and other L1s/L2s) have been some of the largest single sources of losses in DeFi since ~2021.
• Many bridge designs rely on multi-sig or validator sets that, if compromised, can mint or release huge amounts of tokens on a destination chain.
• When a major bridge is hacked, entire ecosystems relying on that bridge's wrapped assets can be affected.

Why protocol-level?

• A bridge is often treated as critical infrastructure: it underpins multiple apps, not just one.

Example B – Application-Level Risk: Smart Contract Bug

• A DeFi lending protocol deploys a new contract that incorrectly checks collateral.
• Attackers borrow more than they should, then dump tokens, causing bad debt.
• The base chain (e.g., Ethereum) continues operating normally; only users of this protocol lose funds.

Why application-level?

• The failure is localized to one protocol and is due to a specific contract bug, not a failure of consensus.

Example C – Oracle Manipulation

• A protocol uses a thinly traded token as collateral and relies on a DEX spot price as the oracle.
• An attacker trades heavily on the DEX to pump the price, borrows against the inflated collateral, then lets the price crash.

Is this technical or economic?

• The smart contract works as coded.
• The exploit relies on economic manipulation of the price feed.
• This sits at the boundary between technical design and economic exploit, which is exactly why cryptoeconomic security is subtle.

4. Classify the Risk: Technical vs Economic

For each scenario, decide whether the primary issue is:

• Technical vulnerability (bug, broken invariant, implementation error), or
• Economic exploit (rational use of rules/incentives to extract value), or
• Mixed.

Write down your classification and a one-sentence justification.

1. Scenario 1: A DEX uses a constant-product AMM (like Uniswap v2). A trader performs a large swap right before a protocol reads the price from that DEX, then swaps back afterward, profiting from the temporary price impact.

• Your classification:
• Why?

1. Scenario 2: A lending protocol forgets to update a user’s debt balance after a partial repayment, allowing them to withdraw more collateral than they should.

• Your classification:
• Why?

1. Scenario 3: A proof-of-stake chain with a small validator set is attacked by an entity that buys/borrows enough stake to control >2/3 of validators and censors specific transactions.

• Your classification:
• Why?

Then compare your reasoning with a peer, or (if working alone) try to argue the opposite classification for each case. This helps you see how technical design and incentives interact.

5. Economic Attacks: MEV, Flash Loans, Governance Attacks

Economic attacks typically follow the rules of the system but use them in unexpected ways.

5.1 MEV (Maximal / Miner / Maximal Extractable Value)

• Definition: The maximum value that a block producer (miner/validator) or other privileged actor can extract from transaction ordering, inclusion, or censorship.
• Common MEV strategies:
• Front-running: Inserting a transaction before a large trade to profit from price movement.
• Back-running: Trading after a large trade to capture arbitrage.
• Sandwich attacks: Placing one trade before and one after a victim’s trade to profit from slippage.
• Since ~2021, MEV-Boost and PBS (Proposer-Builder Separation) on Ethereum have changed how MEV is captured and shared, but MEV as a phenomenon remains central.

5.2 Flash Loans

• Definition: Uncollateralized loans that must be borrowed and repaid within the same transaction.
• If repayment fails, the entire transaction reverts, so the lender is safe.
• Attackers use flash loans to:
• Temporarily gain huge capital
• Manipulate prices (e.g., low-liquidity pools)
• Execute complex multi-step arbitrage or liquidation strategies
• Many high-profile DeFi exploits since 2020 have involved flash loans + oracle manipulation + logic flaws.

5.3 Governance Attacks

• Definition: Attempts to gain control of a protocol’s governance process to pass self-serving or malicious proposals.
• Vectors:
• Vote buying or borrowing governance tokens (sometimes via flash loans) to pass a proposal.
• Exploiting low voter turnout or concentrated token ownership.
• Proposals that look benign but contain malicious upgrade logic.

Key point: These attacks often do not exploit a code bug; they exploit economic design and governance weaknesses.

6. Quick Check: Economic Attacks

Apply your understanding of economic attacks.

7. On-Chain vs Off-Chain Governance

Crypto protocols are governed by a mix of on-chain and off-chain processes.

7.1 On-Chain Governance

• Definition: Governance where proposals and votes are executed on-chain via smart contracts.
• Features:
• Transparent: Votes and outcomes are publicly visible.
• Automatic execution: If a proposal passes, code changes or parameter updates can be applied without off-chain coordination.
• Token-based voting: Typically 1 token = 1 vote (or delegated voting power).
• Examples:
• Many DeFi protocols on Ethereum use on-chain governance contracts to change parameters (fees, collateral factors) or upgrade implementations.

Risks:

• Token concentration: Large holders or VCs can dominate outcomes.
• Flash-loan voting: If not mitigated, attackers can borrow tokens for a single vote.
• Voter apathy: Low turnout makes capture easier.

7.2 Off-Chain Governance

• Definition: Governance where discussion, signaling, and sometimes voting occur off-chain, with upgrades implemented by core devs or multisigs.
• Tools:
• Forums (e.g., governance forums)
• Off-chain voting (e.g., Snapshot) where votes are signatures rather than on-chain transactions
• Core developer calls and community meetings

Benefits:

• Lower cost to vote (no gas fees)
• Richer discussion and iteration before proposals go on-chain

Risks:

• Social centralization: Small groups (core teams, foundations) can have outsized influence.
• Informal power: Reputation and coordination matter as much as token counts.

Most major ecosystems (Ethereum, major DeFi protocols) use a hybrid model: off-chain discussion and signaling + on-chain execution for finalized decisions.

8. Design Exercise: Hardening Governance

Imagine you are designing governance for a new DeFi lending protocol.

You decide to use on-chain token voting for parameter changes (e.g., interest rate models, collateral factors).

Consider each of the following design choices and write 1–2 sentences on how it affects security and risk:

1. Delegated voting (token holders can delegate votes to representatives)

• How might this reduce or increase the risk of governance capture?

1. Quorum requirement (e.g., at least 10% of total voting power must vote)

• How does this interact with low voter turnout and attack difficulty?

1. Timelocks on execution (e.g., a 48-hour delay before a passed proposal is executed)

• How could this help users and other stakeholders respond to malicious proposals?

1. Snapshot at proposal creation (voting power is fixed at the block when the proposal is created)

• How does this mitigate flash-loan-based governance attacks?

After you answer, compare your ideas to best practices used by major protocols like Aave, Compound, or Uniswap, which commonly use timelocks, delegation, and quorum thresholds to reduce governance risk.

9. Forks and Protocol Upgrades: How Communities Respond

When governance fails or communities disagree deeply, they sometimes choose to fork.

9.1 What is a Fork?

• Definition: A fork is a change in the protocol rules that creates a divergence in the blockchain’s history or future.
• Types:
• Soft fork: A backward-compatible rule change; nodes that do not upgrade can still follow the chain, but may reject some new features.
• Hard fork: A non-backward-compatible change; nodes must upgrade to follow the new chain. If some nodes refuse, the chain can split into two independent networks.

9.2 Why Fork?

• Bug fixes / emergencies: Rapid response to critical vulnerabilities.
• Feature upgrades: New opcodes, improved scalability, fee markets (e.g., Ethereum’s EIP-1559 in 2021 changed fee mechanics via a hard fork-style network upgrade).
• Value or governance disputes: Communities may disagree on how to handle major incidents or future direction.

9.3 Historical Context (for understanding governance)

• In earlier years, high-profile events (e.g., The DAO hack in 2016) led to contentious hard forks, splitting communities (e.g., Ethereum vs. Ethereum Classic).
• These events still shape today’s governance culture, emphasizing:
• Social consensus over purely on-chain rules
• The idea that “code is law” is moderated by community values

9.4 Protocol Upgrades Today

• Many major chains (like Ethereum) now use structured processes:
• Formal improvement proposals (e.g., EIPs)
• Multiple testnets and audits
• Client diversity to avoid single points of failure
• Upgrades require coordination between core devs, validators, app developers, and users.

Forks and upgrades show how technical governance (changing code) is inseparable from social governance (convincing humans to adopt the change).

10. Check Understanding: Forks and Governance

Test your understanding of forks in relation to governance.

11. Review Key Terms

Flip these cards (mentally or with a partner) and try to recall the definition before reading it.

12. Synthesis: Connecting Security, Economics, and Governance

To consolidate what you learned, write brief answers (2–3 sentences each) to these prompts:

1. Technical vs Economic Risk

Pick a recent or hypothetical DeFi incident (e.g., an oracle manipulation with flash loans). Describe which parts are technical vulnerabilities and which are economic exploits.

1. Governance Impact

Explain how governance tokens and voting mechanisms in that protocol could mitigate or worsen the risk you described. Consider quorum, timelocks, and token concentration.

1. Fork Decision

Under what conditions do you think the community should consider a fork or major upgrade to address the issue? What trade-offs would they face (e.g., user trust, complexity, fragmentation)?

Try to explicitly connect back to concepts from earlier modules on DeFi primitives (lending, trading, yield) and game theory (incentive compatibility, Nash equilibrium, collusion). This will help you see cryptoeconomic systems as interacting layers of code, markets, and governance.