I looked at the code that was wrong with Cetus last night, and the first thing I was very suspicious about get_delta_b was why this function would convert u256 to u64, which caused the accuracy interception problem. After asking the AI, it is likely that when cetus migrated all the uniswap v3 formulas, because uni uses a fixed point, it needs to be converted to a floating-point number without careful security consideration. This kind of business logic, which belongs to the algorithm level, is difficult to detect in code audits, unless the audit institution also has researchers who are familiar with both algorithms and code. Here's the logic of why AI analyzes the code the way it does: Based on my analysis of the codebase, I can now explain why the author chose to implement it this way get_delta_b functions, and possible causes: Why the author of the function implements get_delta_b way Performance optimization: ) and bitmask directly handle U256 types. This is most likely to improve performance and reduce computational overhead. In DeFi applications, especially high-frequency trading scenarios, performance is critical. The commented out code uses u256::get ,u256::shrw while the current implementation uses bit operations (>> 64 Save gas fees: Operations on the Sui blockchain need to pay gas fees, and more complex operations will consume more gas. Simplifying math can reduce transaction costs, especially for frequently operated AMM core functions. Reduced dependencies: Module functions, and the current implementation reduces calls to these functions, perhaps to reduce dependencies on external libraries, or to avoid problems with some external functions. The code in the comments uses more u256 Solidity to Move porting: In terms of code style, this could be a porting from Ethereum's Solidity code to Sui's Move language. This use of bit manipulation and masking is common in Solidity, especially in AMM implementations such as Uniswap V3. Dealing with fixed point math: The resulting 256-bit result needs to be processed correctly, and shifting 64 bits to the right is a common way to get the correct decimal point position. Fixed point math is often used in AMMs to deal with decimal values. full_math_u128::full_mul Potential problems However, this implementation introduces several problems: Poor code readability: The use of hardcoded masks and displacement operations makes the code difficult to understand and audit. Lack of full bounds checking: Bit operations and type conversion operations lack comprehensive bounds checking, which can lead to unexpected behavior in extreme cases. Commenting code coexists with implementation code: Keeping older versions of commented code indicates that the code may be in a transitional state or not adequately tested, which is dangerous for critical code dealing with financial assets. Integer overflow risk: When dealing with large values, bit operations and transformations can lead to integer overflow, and simplified implementations may lack adequate protection mechanisms. summary It is likely that the author's main reason for implementing this code is to optimize performance and reduce gas costs, while handling fixed-point math calculations in AMMs. However, this optimization, at the expense of code security and readability, may provide attackers with exploitable vulnerabilities, as you can see from the Cetus theft incident you provided. In DeFi projects, security should always take precedence over performance optimization, especially for core functions that handle user assets. It's better to use proven library functions, add comprehensive bounds checks, and conduct adequate security audits.