
Cetus Security Issues Reveal: What Should DeFi Teams Pay Attention To?
TechFlow Selected TechFlow Selected

Cetus Security Issues Reveal: What Should DeFi Teams Pay Attention To?
Starting from Cetus, all DeFi teams should move beyond the limitations of a purely technical mindset and truly cultivate the security risk awareness of "financial engineers."
Author: Haotian
After reading @CetusProtocol's post-mortem security report on the hack, you'll notice a "thought-provoking" phenomenon: the technical details are disclosed with remarkable transparency, and the incident response is textbook-level. Yet, when it comes to the most critical question—the soul-searching "why were we hacked?"—the report appears evasive:
The report devotes extensive space to explaining an error in the `checked_shlw` function of the `integer-mate` library (it should have been ≤2^192 but was actually ≤2^256), classifying this as a "semantic misunderstanding." While technically accurate, this narrative skillfully shifts focus toward external responsibility, portraying Cetus as an innocent victim of this technical flaw.
Here's the problem: if `integer-mate` is an open-source and widely used math library, why did this absurd vulnerability—where 1 token could obtain an astronomical liquidity share—occur specifically in your system?
An analysis of the attack path reveals that for the hacker to execute a perfect attack, four conditions had to be simultaneously met: incorrect overflow checks, large-bit-shift operations, ceiling-rounding rules, and the absence of economic rationality validation.
Cetus happened to be "careless" at every single one of these triggering points—for instance: accepting user inputs like 2^200, employing extremely risky large-bit-shift operations, fully trusting the external library’s check mechanism, and most fatally, executing transactions without any economic sanity check when the system calculated an absurd result like "1 token for an astronomical share."
Therefore, the real points Cetus should reflect on are as follows:
1) Why wasn't proper security testing conducted before adopting a general-purpose external library? Although the `integer-mate` library is open-source, popular, and widely used, Cetus deployed it to manage hundreds of millions of dollars in assets without fully understanding its security boundaries or having contingency plans in case the library failed. Clearly, Cetus lacked even basic supply chain security awareness;
2) Why were astronomical input values allowed without bounds? While DeFi protocols aim for decentralization, mature financial systems become more open yet require clearer boundaries.
When the system permits attackers to input carefully crafted astronomical numbers, the team clearly didn’t consider whether such liquidity demands were reasonable. Even the world’s largest hedge funds couldn’t possibly require such exaggerated liquidity shares. Clearly, the Cetus team lacks risk management personnel with financial intuition;
3) How did multiple rounds of security audits fail to catch this issue beforehand? This inadvertently exposes a fatal misconception: project teams outsource security responsibility to audit firms, treating audits as immunity cards. But reality is harsh: security auditors excel at finding code bugs—who would think to test whether the system might produce absurd exchange ratios?
This kind of cross-disciplinary validation involving mathematics, cryptography, and economics represents the biggest blind spot in modern DeFi security. Audit firms will say, "This is a flaw in the economic model design, not a code logic issue," while project teams complain, "The audit didn’t find anything." Meanwhile, users simply know their money is gone!
Ultimately, this exposes a systemic security shortcoming in the DeFi industry: technically-focused teams severely lack basic "financial risk sense."
Judging from Cetus’s report, the team clearly hasn’t reflected deeply enough.
Rather than merely addressing the technical shortcomings revealed by this hack, I believe starting with Cetus, all DeFi teams must overcome the limitations of pure technical thinking and truly cultivate the risk awareness of "financial engineers."
For example: bring in financial risk control experts to fill knowledge gaps within technical teams; implement multi-party audit mechanisms that include not only code reviews but also essential economic model audits; develop "financial intuition" by simulating various attack scenarios and corresponding countermeasures, and remain vigilant against anomalous operations.
This reminds me of my past experience working at a security firm, and discussions with industry security leaders like @evilcos, @chiachih_wu, @yajinzhou, @mikelee205—all shared this consensus:
As the industry matures, technical bugs at the code level will gradually decrease, while the biggest challenge will be business logic "awareness bugs" stemming from unclear boundaries and ambiguous responsibilities.
Audit firms can only ensure code is bug-free, but achieving "well-defined logical boundaries" requires project teams to have a deeper understanding of the business essence and stronger boundary control capabilities. (Most post-audit hacks leading to blame-shifting incidents stem from this very reason.)
The future of DeFi belongs to teams that not only possess strong coding skills but also demonstrate deep understanding of business logic!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














