QA Report

[code423n4]

Low

Obsolete pragma

The pragma version used is:

pragma solidity 0.8.10;
pragma solidity ^0.8.0;

But recently solidity released a new version with important Bugfixes:

• The first one is related to ABI-encoding nested arrays directly from calldata. You can find more information here.

• The second bug is triggered in certain inheritance structures and can cause a memory pointer to be interpreted as a calldata pointer or vice-versa. We also have a dedicated blog post about this bug.

Apart from these, there are several minor bug fixes and improvements.

The minimum required version should be 0.8.14

Lack of empty address checks

The following methods have a lack checks if the received argument is an address, it's good practice in order to reduce human error to check that the address specified in the constructor or initialize is different than address(0).

address(0):

• NibblVaultFactory.sol#L26
• AccessControlMechanism.sol#L19

AccessControl / Pausable

The contract NibblVaultFactory is AccessControl and Pausable, so the owner could resign while the contract is paused, causing a Denial of Service. Owner resignation while paused should be avoided.

Affected source code:

• NibblVaultFactory.sol#L17

Use encode instead of encodePacked for hashig

Use of abi.encodePacked in NibblVaultFactory is safe, but unnecessary and not recommended. abi.encodePacked can result in hash collisions when used with two dynamic arguments (string/bytes).

There is also discussion of removing abi.encodePacked from future versions of Solidity (ethereum/solidity#11593), so using abi.encode now will ensure compatibility in the future.

Affected source code:

• NibblVaultFactory.sol#L50
• NibblVaultFactory.sol#L70-L71
• NibblVaultFactory.sol#L81
• NibblVaultFactory.sol#L89-L91

Unsafe ERC20 calls

The following code doesn't check the result of the ERC20 calls. ERC20 standard specify that the token can return false if these calls fails, so it's mandatory to check the result of these ERC20 methods.

Reference:

• eip-20

NOTES: The following specifications use syntax from Solidity 0.4.17 (or above) Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned!

Affected source code for transfer:

• Basket.sol#L87
• Basket.sol#L94
• NibblVault.sol#L517
• NibblVault.sol#L526

Lack of ACK during owner change

It's possible to lose the ownership under specific circumstances.

Because an human error it's possible to set a new invalid owner. When you want to change the owner's address it's better to propose a new owner, and then accept this ownership with the new wallet.

Affected source code:

• NibblVault.sol#L485

Non critical

Outdated packages

The packages used are out of date, it is good practice to use the latest version of these packages:

"@openzeppelin/contracts": "^4.5.0",
"@openzeppelin/contracts-upgradeable": "^4.5.0",

Affected source code:

• package.json#L28-L29

Use call to transfer ether

Because to transfer ether the .transfer method (which is capped at 2300 gas) is used instead of .call which is limited to the gas provided by the user. If a contract that has a fallback method more expensive than 2300 gas, it will be impossible for a contract receive funds from Basket contract.

Reference:

• transfer -> The receiving smart contract should have a fallback function defined or else the transfer call will throw an error. There is a gas limit of 2300 gas, which is enough to complete the transfer operation. It is hardcoded to prevent reentrancy attacks.
• send -> It works in a similar way as to transfer call and has a gas limit of 2300 gas as well. It returns the status as a boolean.
• call -> It is the recommended way of sending ETH to a smart contract. The empty argument triggers the fallback function of the receiving address.

Affected source code:

• Basket.sol#L80

Use interval for update window

If a maximum of time is not used during the update proposal, it is possible that the update will be made at the beginning or during deploy it, and after a few years, the change will be accepted, and users won't be aware of that. It is convenient to use a maximum expiration time of the proposal.

Affected source code:

• NibblVaultFactory.sol#L107
• NibblVaultFactory.sol#L131
• NibblVaultFactory.sol#L149
• NibblVaultFactory.sol#L166

Possible loss of token 0

Token 0 is more or less the owner of the Basket contract. If this token is transfered to the wrong address, for example address(this), this ownership could be losed.

It would be convenient to block the transfer when the token is 0 and to is address(this) (address(0) it's already checked.).

Affected source code:

• Basket.sol#L37-L54

Use abstract for base contracts

Abstract contracts are contracts that have at least one function without its implementation. An instance of an abstract cannot be created.

Reference:

• https://docs.soliditylang.org/en/v0.6.2/contracts.html#abstract-contracts

Affected source code:

• Twav.sol#L4
• EIP712Base.sol#L5
• AccessControlMechanism.sol#L8

Wrong initialization

Wrong token name is used during the initialization of NibblVault.INIT_EIP712. NibblVault is used instead of _tokenName.

Affected source code:

• NibblVault.sol#L186

Lack of lock in sell method

if buy have lock, sell should have it, because the danger is the same.

Affected source code:

• NibblVault.sol#L362

[HardlyDifficult]

Merging with https://github.com/code-423n4/2022-06-nibbl-findings/issues/35

[HardlyDifficult]

Merging with https://github.com/code-423n4/2022-06-nibbl-findings/issues/37

[HardlyDifficult]

Merging with https://github.com/code-423n4/2022-06-nibbl-findings/issues/38

[HardlyDifficult]

Very good feedback. Recommendations are clear & specific to the Nibbl contracts.