Unit 6 / 11

DeFi and Protocol Analysis: Liquidity, MEV and Economic Attacks

Gains:

  • Ability to understand DeFi building blocks such as AMM, liquidity pool, oracle and flash loan and use artificial intelligence in mechanism explanation and scenario drafting
  • Being able to distinguish that most DeFi risks are economic/business logic vulnerabilities, not code bugs, and that artificial intelligence is weak in the original economic vulnerability
  • Being able to understand that economic security is proven by simulation, not by thinking, and that oracle addiction is the most fragile point.

DeFi (Decentralized Finance) is the highest value and most attacked domain of Web3. Exchanges, lending protocols, liquidity pools—all run as code, and all move millions of dollars in a hostile environment. In this unit, we will use AI as a protocol analysis assistant; We will learn to understand liquidity, pricing, MEV and economic attacks and where AI is helpful and inadequate in this contextual area.

Basic building blocks of DeFi

  • AMM (Automated Market Maker): An exchange mechanism that sets prices by a formula (e.g. x·y=k) rather than matching buyers and sellers.
  • Liquidity pool: A common fund where users deposit tokens and trade takes place.
  • Lending protocol: Borrowing against collateral; Liquidation occurs when the collateral value decreases.
  • Oracle: The data source that brings the outside world price to the protocol — DeFi's most critical and most fragile dependency.
  • Flash loan: A loan taken without collateral in a single transaction and returned in the same transaction; It has both legitimate uses and an attack tool.

MEV and economic attacks

MEV (Maximal Extractable Value — the value extracted by the authority to order/add/remove transactions) is a risk class specific to DeFi. Pending transactions appear in the public pool (mempool); This visibility opens the door to the following attacks:

  • Front-running: Seeing a profitable transaction and inserting one's own transaction in front of it.
  • Sandwich attack: Placing transactions before and after the victim's purchase and profiting from the price difference.
  • Oracle manipulation: Deceiving the protocol by instantly changing the price of a pool, usually with a flash loan.

These attacks arise not from the "bug" of the code, but from the exploitability of the economic design. This is where AI has the most difficulty: AI that is good at scanning technical code often cannot detect a protocol-specific economic vulnerability.

Attention: The majority of DeFi vulnerabilities are not "code bugs" but economic/business logic vulnerabilities. AI's standard code scanning misses these; This is the field that requires the most human expertise, simulation and modeling.

The role of AI in DeFi analysis

1. Mechanism description. AI is powerful at explaining in plain language how a complex protocol (e.g. a curve-based AMM) works. This provides quick entry into analysis.

2. Generating a scenario/counter-hypothesis. "At what price movement will this debt protocol enter a liquidation crisis?" AI produces scenario drafts with questions such as; these are tested by simulation.

3. Reminding known attack patterns. The AI ​​evokes the patterns of past DeFi attacks (oracle manipulation, reentrancy, liquidation spiral) like a checklist.

4. Simulation plan draft. AI can come up with a plan for which scenarios to test; but the simulation itself is done with the tool (Foundry, Tenderly).

Weak prompt / Strong prompt

Weak prompt:

Is this DeFi protocol safe?

Powerful prompt:

Your role: DeFi protocol analyst. Examine the protocol mechanism below. Consider the following economic attack vectors one by one: oracle manipulation (with flash loan), sandwich/front-running, liquidation spiral, liquidity withdrawal effect. For each vector: how to trigger, what condition is required, possible impact. These are the hypotheses to be tested BY SIMULATION; Don't say "secure/unsafe" for sure. GENERATE Actual attack code; Describe risk for defensive purposes only.

Four copyable templates

1) Mechanism description:

Explain in plain language, step by step, the pricing/liquidity mechanism of this protocol: what happens when a user makes a transaction, how is the price determined, what external dependencies are there? Mark the part you do not understand or leave unclear.

2) Economic attack surface:

Map the economic attack surface of this protocol: what assumptions can be exploited in oracle, liquidity, collateral, liquidation, governance? Write each risk with a condition ("what if"). Present it as a hypothesis to be confirmed by simulation.

3) Stress scenario:

Consider the following scenarios: if the collateral token drops by 50%, if the oracle price deviates by 30% momentarily, if 80% of the liquidity is withdrawn, what will be the protocol? Write down the knock-on effect of each scenario. Do not claim numerical precision; Specify that simulation is required.

4) History attack pattern matching:

Does the design of this protocol bear similar conditions to which of the known DeFi attack patterns (e.g. single-source oracle, flash loan open price)? Point out similarities for defensive purposes; Don't take the exploit step, it will only produce a point of attention.

Three mini cases (in numbers)

Case 1 — Oracle risk spotted early. A team was designing a new debt protocol. During the mechanism explanation, YZ marked the hypothesis that "the price is taken from a single pool and can be manipulated with flash loans." The team confirmed this in the simulation and moved to TWAP + multi-sourcing. Estimated loss avoided: the entire locked value of the protocol. Lesson: AI is valuable in evoking known patterns.

Case 2 — AI missed the original vulnerability. In another protocol, the vulnerability was a unique economic error resulting from the interaction of two mechanisms (reward + liquidation). The AI ​​found each mechanism "flawless" one by one; Couldn't see the interaction. Human modeler and simulation captured. Lesson: while the components are right, the economics of the whole are AI's blind spot.

Case 3 — The simulation plan saved time. One analyst drafted 15 different stress scenarios into the AI ​​instead of planning them by hand; then ran it at Foundry. Planning went down from 1 day to 2 hours; but the interpretation of the results and the decision were man's. Lesson: AI plans, vehicle measures, human decides.

The indispensability of simulation

In DeFi, security is not proven by “thinking”; It is tested by simulation. The economic robustness of a protocol can be understood by numerically running different price, liquidity and attack scenarios. AI can plan and draft the code of these simulations; but it is the tools and people who produce and interpret the results. The statement "probably durable" produced by the AI ​​is not a simulation result and cannot be presented as such.

Tip: When you receive a DeFi risk assessment from AI, you should ask each hypothesis “what simulation do I test this with?” Turn it into a question. A security claim that cannot be tested is not an assurance in DeFi.

Common mistakes

  • Scanning the economic deficit like a code bug. DeFi risks are mostly in business logic.
  • Trusting the AI ​​to say "safe" and skipping the simulation. Testing is required.
  • Validating components one by one and skipping interaction. The economy of the whole is critical.
  • Trusting Oracle from a single source. The most common DeFi disaster.
  • Ignoring MEV/front-running. Forgetting the fact of public mempool.
  • Generating exploit code. Only defensive analysis is legitimate.

In summary

  • DeFi is a high-value and hostile space; The risks are mostly in economic/business logic.
  • MEV, front-running, sandwich and oracle manipulation are classes of attacks specific to DeFi.
  • AI is strong in mechanism explanation and scenario drafting; The original economic deficit is weak.
  • Economic security is proven by simulation, not thinking; AI plans, vehicle measures.
  • Oracle dependency is the most vulnerable point of DeFi; multiple resources and TWAP required.

Application task

Choose an AMM or lending protocol (with clear documentation). Apply the "mechanism description" and "economic attack surface" prompts to the AI. For every risk hypothesis the AI ​​produces, “what simulation would I test this with?” Answer the question. Then find the actual audit report of that protocol and compare the actual findings with the risks flagged by the AI: What did the AI ​​catch, what did it miss?

checklist

  • [ ] I discussed the risks in two dimensions: code + economy.
  • [ ] I evaluated MEV/front-running.
  • [ ] I also examined the Oracle dependency.
  • [ ] I questioned the interaction of the components (the whole economy).
  • [ ] I connected each hypothesis to a simulation plan.
  • [ ] I replaced the AI's "safe" with simulation.
  • [ ] I only analyzed for defensive purposes.