Author: Karl Marx OnChain

Translation: Yuliya, PANews

In 2024, losses in the DeFi sector reached up to $1.029 billion, with losses of $649 million in 2025, and $137 million stolen in just the first quarter of 2026. PANews Note: Since April 2026, DeFi losses have exceeded $600 million.

Why do hacking incidents keep occurring? Why do we always ignore the same danger signals? When stripping away the surfaces of these vulnerabilities, you will find that they do not happen randomly, but are traceable.

This article outlines the underlying patterns and easily overlooked early warning signals behind significant DeFi security incidents. Based on an in-depth review of over a hundred attack cases, the article provides core prevention advice at the end.

The Truth and Classification of Frequent Vulnerabilities

Before we begin, it is necessary to clarify why we categorize these vulnerabilities into different types.

Fundamentally, failures in DeFi often occur at specific levels of the system, and each layer's collapse is fundamentally different:

• Code level: Fails when assumptions are not enforced. There are no obvious logical errors, but edge cases, constraints, or invariants have never been fully checked.

• Infrastructure: Fails when trust is placed in a potentially compromised system.

• Business logic: Fails when "playing by the rules" itself becomes a means of attack.

Below is a structured summary of typical cases of various types of vulnerabilities:

1. Infrastructure: Control is Correct, but Context is Incorrect

Infrastructure fails when power is exercised without complete awareness (rather than when keys are stolen). In various security incidents, we consistently observe a pattern: the right person signed the transaction, used the correct permissions, and the system operated exactly as designed.

However, funds are still lost. Because the system verifies authenticity, not intent. A valid signature can only prove who signed it but cannot prove they truly understood what they were signing. This gap between verification and understanding is the breeding ground for infrastructure collapse.

@DriftProtocol: They Signed Too Early

The transaction is valid, and the signature is real. They just didn’t anticipate that it would be used afterward.

It was approved during a routine check when nothing happened. Then one day it was executed. Nothing was forged or altered.

The problem is simple: they signed something but did not control when it was used.

@Bybit_Official: They Signed the Wrong Thing

The system is functioning normally, and the signature is valid. People simply signed something different from what they imagined.

What they saw was a normal transfer, and then they approved it. But under the hood, it was changing the control of the wallet. In the usual sense, nothing was hacked; everything followed the rules.

The problem is simple: what they saw... was not what they signed.

@UXLINKofficial: They Had the Right to Do So

The system allowed it, and the permissions were valid. No keys were stolen, nor was there any bypassing of checks.

The administrator role was changed, and ownership was reassigned. All of this was done through legitimate calls, and everything operated as designed.

The problem is simple: the system granted sufficient power and assumed it would not be abused.

2. Code: Places Where Assumptions Are Not Enforced

Code vulnerabilities do not stem from obvious bugs. They often arise from those that work as intended but do not function correctly under all conditions.

• Rules exist but are not enforced everywhere;

• Edge cases are ignored until they are maliciously triggered;

• Mathematical formulas theoretically work but collapse in code implementation;

• Security checks cover expected paths but do not cover actual attack paths.

In short, code fails where its assumptions no longer hold.

Bunni: The Mathematical Principle Was Fine Until It Went Wrong

The system underwent auditing, and they confirmed that the code was correct. The model made perfect sense on paper: liquidity, pricing, everything checked out.

But in practice, minor rounding errors occurred. And they did not offset but continually accumulated. The attacker did not disrupt the system; they simply repeated it: over and over. The problem is simple: the mathematical theory is correct, but the code implementation is not precise.

@Balancer: Small Errors, Repeatedly Occurring

The system is functioning normally, and the mathematical calculations are correct. Each transaction incurs very small rounding losses, almost negligible.

But it did not reset; instead, it accumulated. The attacker did not exploit it just once; they exploited it multiple times in a process.

The problem is simple: if a small error can be repeated enough times, it will snowball into a big error.

Venus: Rules Exist, Just Not Ubiquitous

The system has a limit, and the checking mechanism is implemented. But only in one place.

Through another path, the same rules do not apply. The attacker did not bypass the system; they merely circumvented that checkpoint. The problem is simple: a rule not enforced everywhere is equivalent to no rule at all.

3. Business Logic: When the System Trusted the Wrong Thing

The system follows its own rules, trusting prices. If the price rises, you can borrow more funds.

Thus, the attacker purchased their own assets, artificially inflating the price. Now the system thinks they are wealthy and allows them to borrow real value assets. Then they cash out. Nothing was destroyed; the system just trusted something that is easily manipulable.

Mango: He Made Himself Look Wealthy

The system trusted the price: higher price → more collateral → more borrowing.

The attacker bought large amounts of low liquidity tokens, causing the price to rise. Then they borrowed real assets from the protocol using this inflated price. Afterward, they stopped supporting the price, and it crashed. Collateral became insufficient, but the borrowed funds had vanished. Nothing was hacked; the system merely believed a price that could be manipulated.

Impermax: Prices Too Easily Shaken

The system trusted prices, but the market was too weak.

The attacker borrowed tokens and then traded against a low liquidity pool. Prices fluctuated severely, beyond what they should have. Now the system deemed that position unsafe and forced liquidation. The attacker was prepared for this and took the profits. Nothing was destroyed; the price was just too easily shaken.

Final Lesson: How to Survive and Develop?

Among all these vulnerabilities, one thing is clear: you do not need to make mistakes to lose money; you only need to be exposed to risks when the system collapses.

The issue is not that protocols are broken, but that they rely on things that can go wrong: assumptions, context, or prices. Therefore, our goal is not to seek perfect systems, but to control your degree of trust in them.

In practice, this means:

• Do not blindly trust what you see on the interface.

• Do not assume that rules will always protect you.

• Do not treat prices or yields as absolute truths.

• Avoid exposing all assets in one place, as failures often occur very quickly and without warning.

Survival comes down to limiting damage: use systems that can enforce constraints, avoid easily manipulatable setups, and always retain the ability to exit.

In DeFi, you cannot win by trusting the system; you can only survive by controlling how much it can hurt you.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。