In Solidity, if a function has multiple modifiers they are executed in the order specified. If checks or logic of modifiers depend on other modifiers this has to be considered in their ordering.

The flashWithdraw(), redeem() and withdraw() functions from the InceptionVault contract have multiple modifiers with one of them being nonreentrant which prevents reentrancy on the functions. This should ideally be the first one to prevent even the execution of other modifiers in case of reentrancies.

While there is currently no obvious vulnerability with nonreentrant being the last modifier in the list, placing it first ensures that all other modifiers are executed only if the call is non-reentrant. This is a safer practice and can prevent potential issues in future updates or unforeseen scenarios.

Switch modifier order to consistently place the nonReentrant modifier as the first one to run so that all other modifiers are executed only if the call is non-reentrant.

Remediation Plan

ACKNOWLEDGED: The Tagus Labs team made a business decision to acknowledge this finding and not alter the contracts.

The __InceptionVault_init() function from the InceptionVault contract contains a TODO comment that may indicates that the function has not been not completely implemented. This incomplete implementation can lead to unexpected behavior and/or potential vulnerabilities within the contract.

minAmount = 100;

/// @notice TODO

protocolFee = 50 * 1e8;

Ensure that all TODO comments are resolved and the function is fully implemented.

Remediation Plan

SOLVED: The Tagus Labs team has addressed the finding in commit 0229f48e38eacf23baa53c33190c968c8d2e324f by following the mentioned recommendation.

From Solidity versions 0.8.20 through 0.8.24, the default target EVM version is set to Shanghai, which results in the generation of bytecode that includes PUSH0 opcodes. Starting with version 0.8.25, the default EVM version shifts to Cancun, introducing new opcodes for transient storage, TSTORE and TLOAD.

In this aspect, it is crucial to select the appropriate EVM version when it's intended to deploy the contracts on networks other than the Ethereum mainnet, which may not support these opcodes. Failure to do so could lead to unsuccessful contract deployments or transaction execution issues.

Make sure to specify the target EVM version when using Solidity versions from 0.8.20 and above if deploying to chains that may not support newly introduced opcodes. Additionally, it is crucial to stay informed about the opcode support of different chains to ensure smooth deployment and compatibility.

Remediation Plan

ACKNOWLEDGED: The Tagus Labs team made a business decision to acknowledge this finding and not alter the contracts.

The files in scope currently use floating pragma version ^0.8.22, which means that the code can be compiled by any compiler version that is greater than or equal to 0.8.22, and less than 0.9.0.

However, it is recommended that contracts should be deployed with the same compiler version and flags used during development and testing. Locking the pragma helps to ensure that contracts do not accidentally get deployed using another pragma. For example, an outdated pragma version might introduce bugs that affect the contract system negatively.

Lock the pragma version to the same version used during development and testing.

Remediation Plan

ACKNOWLEDGED: The Tagus Labs team made a business decision to acknowledge this finding and not alter the contracts.

The InceptionVault contract imports the IRebalanceStrategy interface but does not use it in the contract. This can be considered as unnecessary code and should be removed to keep the code clean and easy to read.

Remove the unused IRebalanceStrategy import statement.

Remediation Plan

SOLVED: The Tagus Labs team has addressed the finding in commit 0229f48e38eacf23baa53c33190c968c8d2e324f by following the mentioned recommendation.

Several functions throughout the files in scope currently define several functions with the public visibility modifier, even though the functions are not called from within the contract, possibly resulting in higher gas costs than necessary.

In the case of Solidity public functions, arguments of the functions are copied to memory. While on the other hand, functions with external visibility can directly read arguments from calldata. Since calldata is cheaper to access than memory, external functions result in a lower execution cost than public functions.

The affected functions are:

• deposit()

• depositWithReferral()

• redeem()

• getTotalDeposited()

• getDelegatedTo()

• getPendingWithdrawalOf()

• maxDeposit()

• maxRedeem()

Modify the aforementioned functions with the external visibility modifier.

Remediation Plan

SOLVED: The Tagus Labs team has addressed the finding in commit 0229f48e38eacf23baa53c33190c968c8d2e324f by following the mentioned recommendation.

Throughout the code in scope, there are several instances of unoptimized for loop declarations that may incur in higher gas costs than necessary. The affected functions are:

• redeem()

• isAbleToRedeem()

• getTotalDelegated()

• _verifyDelegated()

Optimize the for loop declarations to reduce gas costs. Best practices include: the non-redundant initialization of the iterator with a default value (i = 0 instead of simply i), the use of the pre-increment operator ( ++i). Additionally, when reading from storage variables, it is recommended to reduce gas costs significantly by caching the array to read locally and iterate over it to avoid reading from storage on every iteration:

Moreover, if there are several loops in the same function, the i variable can be re-used, to be able to set the value from non-zero to zero and reduce gas costs without additional variable declaration. For example:

uint256[] memory arrayInMemory = arrayInStorage;

uint256 i;
for (; i < arrayInMemory.length ;) {
  // code logic
  unchecked { ++i; }
}

delete i;

uint256[] memory arrayInMemory2 = arrayInStorage2;

for (; i < arrayInMemory2.length ;) {
  // code logic
  unchecked { ++i; }
}

Remediation Plan

ACKNOWLEDGED: The Tagus Labs team made a business decision to acknowledge this finding and not alter the contracts.