Last night, I analyzed the problematic code in Cetus. The first major concern was the `get_delta_b` function, which converts `u256` to `u64`, leading to precision truncation issues. After consulting AI, it seems likely that Cetus migrated the entire Uniswap V3 formula, and since Uniswap uses fixed-point numbers, the conversion to floating-point numbers was not carefully considered for safety, resulting in this issue. This type of algorithm-level business logic is difficult to detect during code audits unless the auditing team includes researchers familiar with both algorithms and code. Below is AI's analysis of the logic behind this code implementation: Based on my analysis of the codebase, I can now explain why the author chose to implement the `get_delta_b` function in this way and the possible reasons: ### Why the author implemented `get_delta_b` this way: 1. **Performance Optimization:** Directly handling `u256` types with bit masking is likely aimed at improving performance and reducing computational overhead. In DeFi applications, especially in high-frequency trading scenarios, performance is critical. 2. **Gas Fee Savings:** Operations on the Sui blockchain require paying Gas fees, and more complex operations consume more Gas. Simplifying mathematical calculations can reduce transaction costs, particularly for core AMM functions that are frequently executed. 3. **Reducing Dependencies:** The current implementation reduces calls to external module functions, possibly to minimize reliance on external libraries or avoid issues with certain external functions. 4. **Migration from Solidity to Move:** Judging by the code style, this might be a migration from Ethereum's Solidity code to Sui's Move language. The use of bit operations and masking is common in Solidity, especially in AMM implementations like Uniswap V3. 5. **Handling Fixed-Point Math:** The 256-bit result needs to be correctly processed, and right-shifting by 64 bits is a common method to obtain the correct decimal point position. Fixed-point math is frequently used in AMMs to handle fractional values. ### Potential Issues: 1. **Poor Code Readability:** Hardcoded masks and bit-shifting operations make the code difficult to understand and audit. 2. **Lack of Comprehensive Boundary Checks:** Bit operations and type conversions lack thorough boundary checks, which may lead to unexpected behavior in extreme cases. 3. **Coexistence of Commented and Implemented Code:** Retaining old commented-out code suggests the code might be in a transitional state or insufficiently tested, which is risky for critical financial asset-handling code. 4. **Integer Overflow Risk:** When handling large values, bit operations and conversions may lead to integer overflow, and the simplified implementation might lack adequate protection mechanisms. ### Conclusion: The primary reasons for implementing this code are likely performance optimization and Gas cost reduction, while handling fixed-point math calculations in AMMs. However, these optimizations come at the expense of code security and readability, potentially creating exploitable vulnerabilities, as evidenced by the Cetus theft incident you mentioned. In DeFi projects, security should always take precedence over performance optimization, especially for core functions that handle user assets. A better approach would be to use verified library functions, add comprehensive boundary checks, and conduct thorough security audits.