Fractional v2 contest - fatherOfBlocks's results

Vault.sol

• L17/25/26 - If there are only two possible values, it is not consistent to use a uint256, also taking into account the gas consumption it generates, it is much more correct to use a bool to define the nonce.

IBaseVault.sol

• L4- An IModule import is performed and it is never used.

IERC20.sol

• It does not comply with the IERC20 standard defined in the EIP20 (https://eips.ethereum.org/EIPS/eip-20) and has that name, this is somewhat confusing, since it has a name that refers to a standard with an already defined structure, which does not fulfill this contract, therefore it would be better to use another name.

IERC721.sol

• It does not comply with the IERC721 standard defined in the EIP721 (https://eips.ethereum.org/EIPS/eip-721) and has that name, this is somewhat confusing, since it has a name that refers to a standard with an already defined structure, which does not fulfill this contract, therefore it would be better to use another name.

IERC1155.sol

• It does not comply with the IERC1155 standard defined in the EIP1155 (https://eips.ethereum.org/EIPS/eip-1155) and has that name, this is somewhat confusing, since it has a name that refers to a standard with a structure already defined, which does not fulfill this contract, therefore it would be better to use another name.

IMmigration.sol

• L4/5- Imports of Permission, State are performed and are never used.

IMinter.sol

• L4- A Permission import is performed and is never used.

IProtoform.sol

• L4- An IModule import is performed and it is never used.

Migration.sol

• L4/5/6/7/12 - Auction, IERC20, IERC721, IERC1155, Permission imports are performed and are never used.

• L37/39/53 - The variables in storage buyout and registry are only set in the constructor and have no setter, so gas could be saved by making the variables immutable.

• L520/537 - Inputs are requested in one order and then used completely in another order, it makes more sense that they are requested in the order they are used within the function.

• L527/528 - It should be validated that the _lastTotalSupply input is not zero, otherwise it would revert.

Minter.sol

• L14 - The variable in storage supply is only set in the constructor and does not have a setter, therefore gas could be saved, making the variable immutable.

• L24/32 - The IMinter interface exists, but it only has one function, therefore the getLeafNodes() and getPermissions() functions, which are not in the interface, return arrays with a single internal value. This could be modified and that they directly return the value, generating less gas expenses and actually fulfilling what the code does.

BaseVault.sol

• L19 - The variable in storage registry is only set in the constructor and has no setter, so gas could be saved by making the variable immutable.

Supply.sol

• L5- An import of IVaultRegistry is performed and it is never used.

Transfer.sol

• L4/5/6- IERC20, IERC721, IERC1155 are imported and are never used.

FERC1155.sol

• L37/45 - Gas can be saved if instead of using a modifier a private view function is used.

• L246/247 - You could save gas by creating a variable in memory of royaltyAddress[_id] and use it in the definition of receiver and royaltyAmount.

• L263/275/297 - require can be replaced by ifs and custom errors.

• L339/363 - Less gas costs are generated if one makes ++variable, instead of variable++

Vault.sol

• L39/40 - If a variable in memory is only going to be used once, the least expensive thing is to directly use it where it is needed.

• L62/63 - It is less expensive to validate first than the owner != msg.sender, since if there are two premises that must be correct, the least expensive one is always validated first, since if it is false, the most expensive one would not be executed .

• L78/104 - It is not necessary to create a variable and define its default value, since it generates an extra cost and already has that value.

• L78/104 - It is less expensive to make ++variable, instead of variable++.

VaultFactory.sol

• L38/47/68/69 - If a variable in memory is only going to be used once, the least expensive thing is to directly use it where it is needed.

• L77 - It is less expensive to make ++variable, instead of variable + 1.

Migration.sol

• L232/233 - If a variable in memory is only going to be used once, the least expensive thing is to directly use it where it is needed.

• L508 - Less gas costs are generated if one makes ++variable, instead of variable++

Minter.sol

• L56/60 - If a variable in memory is only going to be used once, the least expensive thing is to directly use it where it is needed.

MerkleBase.sol

• L51 - It is not necessary to set a variable with its default value, this generates extra expenses.

• L51/62/63/78/80/89/93/110 - In the for loop, gas could be saved by creating a variable in memory of _modules.length, since this would save in each iteration having to consult the length of an array .

• L92/97/137/138/147/148 - It is less expensive to do --variable or ++variable than for example: variable + 1 or variable--

BaseVault.sol

• L64/83/107 - It is not necessary to set a variable with its default value, this generates extra costs.

• L130 - In the for loop, gas could be saved by creating a variable in memory of _modules.length, since this would save in each iteration having to consult the length of an array.