Security
Last updated
Last updated
BitFLUX is a stable AMM that is a fork of Saddle Finance, one of the pioneers of correlated asset AMM in DeFi. BitFLUX operates as a fully autonomous market maker without relying on middlemen, order books, or human market makers. This decentralization reduces counterparty risk and enhances security for LPs
The extensive and rigorous audits that have been done include;
Non-compliance With Curve Implementation BitFLUX Response: We recognize that our implementation differs from Curve’s original design in certain areas, such as calculateTokenAmount, getAdminBalance, and stopRampA. These differences were intentional design choices made to optimize performance and improve usability for our specific use case. For example, returning a positive amount when the total supply is zero in calculateTokenAmount simplifies initial liquidity provision without affecting pool state or security. Similarly, our additional check in stopRampA ensures that transitions are handled more safely without introducing any negative side effects.
Remarks: While our implementation deviates from Curve’s original design, these changes were made deliberately to enhance functionality and security for our platform. We believe these optimizations are justified and do not introduce any risks or unintended behavior.
Potential User Restrictions In Liquidity Contributions BitFLUX Response: We acknowledge that there is potential for user-specified values in meta_amounts[i] to be overwritten by base_lp_received. However, this behavior is intentional and designed to ensure that liquidity contributions are handled efficiently. In cases where users provide liquidity with both base LP tokens and meta tokens, it is necessary to adjust meta_amounts[i] to reflect the actual amount received from the base pool. This is to make sure accurate accounting and prevents discrepancies between user expectations and actual liquidity added.
Suboptimal Gas Usage Due To Post-increment In Loops
BitFLUX Response: We acknowledge that using post-increment (i++) instead of pre-increment (++i) can lead to marginally higher gas usage. However, this difference is negligible in practice and does not significantly impact overall gas efficiency. Given that post-increment is more widely used and understood by developers, we have chosen to prioritize readability and consistency across our codebase over micro-optimizations.
Race Condition In Allowance Updates With Approve BitFLUX Response: We acknowledge that the approve method can introduce a race condition if a spender front-runs the transaction and uses the current allowance before it is updated. However, in our contract, this risk is mitigated by the specific context in which approve is used. The approve function is only called within tightly controlled internal logic, where the sequence of operations ensures that no external actor can exploit the allowance before it is consumed. Additionally, we use approve only with tokens that strictly follow the ERC-20 standard, which further reduces the likelihood of an issue.
Remarks: While we understand the general concerns regarding approve, we believe that in our specific use case, the risk of a race condition is minimal due to the controlled environment and token compliance. Therefore, we do not see a need to switch to safeIncreaseAllowance, as it would introduce unnecessary complexity without providing significant security benefits.
Use Of Standard Transfer Methods May Lead To Undetected Failures BitFLUX response: Router contract already utilizes OpenZeppelin's SafeERC20 library in several parts of the contract. For example, functions such as swapFromBase, swapToBase, and removeLiquidity already use safeTransferFrom and safeTransfer to ensure secure token transfers. This is to make sure that transfers either succeed or revert, preventing issues with tokens that do not return a boolean on success.
There are specific cases where functions make direct calls to transfer and transferFrom. These are mainly used when interacting with well-known tokens, such as LPs, which strictly follows ERC-20 standards.
Remarks:
So for LPs, we are confident that the tokens behave as expected (i.e., it returns a boolean on success), making the use of OpenZeppelin's safe wrappers unnecessary. This approach helps optimize gas usage without compromising security.
Missing Protection Against Potential Reentrancy Attacks BitFLUX Response: Reentrancy protection is indeed crucial for preventing malicious recursive calls. We have already implemented reentrancy protection using OpenZeppelin’s ReentrancyGuard in critical areas where external calls are made. However, for other functions where reentrancy risks are minimal or non-existent (e.g., pure view functions or internal operations), we have opted not to apply reentrancy protection to avoid unnecessary gas costs.
Remarks: We believe that reentrancy protection has been applied appropriately where needed. Adding reentrancy guards universally would increase gas costs without providing significant security benefits in many cases.
Potential Handling Errors Due To Duplicate Token Entries In Liquidity Functions BitFLUX Response: We acknowledge that allowing duplicate token entries in liquidity functions could theoretically lead to handling errors. However, our contract’s internal logic ensures that duplicate entries are processed correctly without causing unexpected behavior. This is a design decision to handle each token individually, even if duplicates exist in the input array, we make sure that all tokens are accounted for properly during liquidity operations.
Remarks: Although duplicate token entries may seem problematic at first glance, our contract’s logic ensures that they are handled appropriately. Therefore, we do not believe additional checks for duplicates are necessary at this time.
