Nex Labs Cross Chain security record

IndexFactory::swap takes in a _swapFee parameter which calls SwapHelpers::swap as poolFee. Now poolFee is checked to be greater than 0 to run the swapVersion3 code block and if it is 0 it will run the swapTokensv2 (else block) instead because as per the NATSPEC comment on the swap function, 2 or 3 is expected to signify v2 or v3 respectively. Only the if block will run in any scenario because poolFee is set to 2 or 3 which is always greater than 0

The gasLimit specifies the maximum amount of gas CCIP can consume to execute ccipReceive() on the contract located on the destination blockchain. It is the main factor in determining the fee to send a message. Unspent gas is not refunded.

The IndexFactory contract implements a fee system for token redemptions using basis points (BPS). The fee calculation is performed in the _handleReceivedRedemption() function when processing cross-chain redemption requests. However, there is a critical error in how the swap fee is handled. In the contract, the fee rate is documented and used elsewhere as: uint8 public feeRate; // 10/10000 = 0.1% However, in _handleReceivedRedemption(), the swap fee is hardcoded to 3000 This leads to a fee of 3000 basis points (30%) being charged instead of the expected 0.3% (30 basis points), representing a 100x increase in the fee rate compared to what users would expect based on the documentation and other parts of the contract.

The swap() function in IndexFactory.sol is intended to support both Uniswap V3 and V2 swaps based on the _swapFee parameter. However, due to input validation requirements in multiple functions, the code always executes the V3 swap path, making the V2 swap functionality unreachable. The issue stems from several functions requiring _swapFee > 0 in their validation:<br>1. issuanceIndexTokens() requires _tokenInSwapFee > 0<br>2. redemption() requires _tokenOutSwapFee > 0<br>3. _handleReceivedRedemption() hardcodes fee as 3000<br>These requirements force the swap() function to always take the V3 path since the SwapHelpers.swap() implementation using logic in the image This means the V2 fallback path is never taken, potentially leading to failed swaps if:<br>1. The token pair doesn't exist on Uniswap V3<br>2. The V3 pool has insufficient liquidity<br>3. The specified fee tier doesn't exist for the pair<br>

getAmountOut() accepts a uint256 parameter amountIn but silently truncates it to uint128 when calling estimateAmountOut(), which could lead to incorrect calculations for large token amounts. In IndexFactoryStorage.sol, the getAmountOut() function is used to calculate expected output amounts for token swaps and is a critical component for determining portfolio balances. This truncation could lead to incorrect calculations if the input amount exceeds type(uint128).max, particularly when calculating large portfolio balances through getPortfolioBalance().

The failure to disable initializers at the constructor level of the proxy upgradeable contract raises concern as it is susceptible to exploit. This oversight presents the potential of attackers initializing the implementation contract itself.

The failure to disable initializers at the constructor level of the proxy upgradeable contract raises<br>concern as it is susceptible to exploit. This oversight presents the potential of attackers initializing<br>the implementation contract itself.

The failure to disable initializers at the constructor level of the proxy upgradeable contract raises concern as it is susceptible to exploit. This oversight presents the potential of attackers initializing the implementation contract itself.

These contracts implement the pausable functionality that prevents users from calling important en try points in time of emergency. In the IndexFactory, the internal functions (_pause and _unpause) of the Pausable contract were appropriately invoked and the external functions had onlyOwner modifier. However, the implementation is incomplete as the “whenNotPaused” modifier was not attached to any critical functions. This implies that in time of emergency when the admin calls the pause function, the activity of the contract does not exactly pause. Users will proceed with their activity

These contracts implement the pausable functionality that prevents users from calling important en try points in time of emergency. In the IndexFactory, the internal functions (_pause and _unpause) of the Pausable contract were appropriately invoked and the external functions had onlyOwner modifier. However, the implementation is incomplete as the “whenNotPaused” modifier was not attached to any critical functions. This implies that in time of emergency when the admin calls the pause function, the activity of the contract does not exactly pause. Users will proceed with their activity