Nex Labs Cross Chain

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.

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

It was noticed that the minAmountOut is set to zero during interactions with the AMM router (Uniswap) for swaps. These parameters are intended to protect against slippage; setting them to zero exposes transactions to slippage, potentially resulting in receiving or adding smaller amounts than intended.

Identical to swapExactTokensForTokens, but succeeds for tokens that take a fee on transfer <a href="https://docs.uniswap.org/contracts/v2/reference/smart-contracts/router-02#swapexacttokensfor" target="_blank">https://docs.uniswap.org/contracts/v2/reference/smart-contracts/router-02#swapexacttokensfor</a> tokenssupportingfeeontransfertokens

The Index smart contract integrates Chainlink oracle for price derivation. However, when it fetches the price of a token, it fails to check that the price value is not stale as it is possible for an attacker to manipulate this.

The mint function of the IndexToken contract has 5 require statements to check for address validity and the supply cap being less or equal to the supplyCeiling, however mintToFeeReceiver() function does not have a similar check for token supply minted. This would make the owner able to mint new tokens above the supplyCeiling set and also cause a DOS the next time an address with MINTER role calls mint() because totalSupply() + amount would already have exceeded the supplyCeiling. require(totalSupply() + amount <= supplyCeiling, "will exceed supply ceiling"); If the owner address gets hijacked at any point, the compromised account would be able to mint new tokens without any restrictions leading to economic loss for legitimate users of the protocol.