Swivel v3 contest - fatherOfBlocks's results

Marketplace/Marketplace.sol

• All functions use letters to refer to the function inputs, this is something that could be more descriptive if the names represented the value they actually have.

Marketplace/Erc20.sol

• L78 - If the contract or the address receiving the approve is an attacking address, it could front run to spend the approve when the owner tries to reduce or change the approve for the attacking address.

• This code is repeated in Creator/Erc20.sol and tokens/Erc20.sol

Marketplace/FixedPointMathLib.sol

• This code is repeated in Creator/FixedPointMathLib.sol and tokens/FixedPointMathLib.sol

Creator/Creator.sol

• All functions use letters to refer to the function inputs, this is something that could be more descriptive if the names represented the value they actually have.

Creator/LibFuse.sol

• This code is repeated in Marketplace/LibFuse.sol, VaultTracker/LibFuse.sol and tokens/LibFuse.sol

Creator/Compounding.sol

• This code is repeated in tokens/Compounding.sol

Creator/LibCompound.sol

• This code is repeated in Marketplace/LibCompound.sol, VaultTracker/LibCompound.sol and tokens/LibCompound.sol

Creator/Erc20.sol

• L78 - If the contract or the address receiving the approve is an attacking address, it could front run to spend the approve when the owner tries to reduce or change the approve for the attacking address.

Creator/ZcToken.sol

• L31 - Several storage variables are set in the constructor that are immutable but are not validated if they are different from zero and if they comply with the interface. This would leave many functions with a DoS, forcing a redeploy of the contract.

• L43/52/70/79/88 - In the view functions, a variable could be created in memory and validate that IRedeemer(redeemer).markets(protocol, underlying, maturity).maturityRate) != 0, in order to display the corresponding message, in these functions.

• This code is repeated in tokens/ZcToken.sol

VaultTracker/VaultTracker.sol

• L49 - The addNotional can be used to edit a vault already created, this is a contradiction between the name of the function and the functionality it performs. A more correct name would be setNotional().

Swivel/Swivel.sol

• L33/72 - aaveAddr could be immutable, since it is only set in the constructor.

• L111/388 - If in the validation of line 118 (amount > o.premium) the two values ​​are zero, it would not revert. This code would revert on line 127 when doing a division by zero, without a correct message as to why it would revert.

• L495 - Instead of validating that len ​​== d.length and otherwise reverting, it would validate that len ​​== 4 && d.length == 4, since otherwise a revert would be generated without explaining why within the for loop (if len = = d.length, but they are > 4).

• All functions use letters to refer to the function inputs, this is something that could be more descriptive if the names represented the value they actually have.

Swivel/Swivel.sol

• L100/269/418/564 - Instead of i++, you can save a little more gas by doing ++i;

• L140/141/166/167/201/202/232/233/296/298/326/328/362/363/387/390/394/395/549/561/562/579/580/656/658/673/675 - It is not necessary to create a variable in memory if it is only going to be used once.

Marketplace/Marketplace.sol

• L95 - The validation of block.timestamp < m, could be done in the first line of the function, since it only requires one input. Therefore, it is not necessary to lift from storage, market.

• L203/207/216/218/220/228/229 - It is not necessary to create a variable in memory if it is only going to be used once.

• L341/346 - Instead of using a modifier, you could save gas by using a private view function.

Creator/Creator.sol

• L63 - Instead of using a modifier, you could save gas by using a private view function.

Creator/VaultTracker.sol

• L54/59/93/123/165/181/184/222 - When we have to validate that a uint256 is > 0 it is less expensive to make variable != 0.

• L65/67/130/138/191/193/228/230 - It is not necessary to create a variable in memory if it will only be used once.

• L248 - Instead of using a modifier, you could save gas by using a private view function.

VaultTracker/VaultTracker.sol

• L54/59/93/123/165/181/184/222 - When we have to validate that a uint256 is > 0 it is less expensive to make variable != 0.

• L65/66/100/102/130/138/172/174/191/193/228/230 - It is not necessary to create a variable in memory if it is only going to be used once.

• L248 - Instead of using a modifier, you could save gas by using a private view function.