nibbl-smartcontracts/contracts/Basket.sol:43: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/Basket.sol:70: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/Basket.sol:93: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:506: for (uint256 i = 0; i < _assetAddresses.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:525: for (uint256 i = 0; i < _assets.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:547: for (uint256 i = 0; i < _assets.length; i++) {
Unchecked increment can be used in for-loop
Newer versions of the Solidity compiler will check for integer overflows and underflows automatically. This provides safety but increases gas costs.
When an unsigned integer is guaranteed to never overflow, the unchecked feature of Solidity can be used to save gas costs.
A common case for this is for-loops using a strictly-less-than comparision in their conditional statement, e.g.:
uint256 length = someArray.length;
for (uint256 i; i < length; ++i) {
}
In cases like this, the maximum value for length is 2**256 - 1. Therefore, the maximum value of i is 2**256 - 2 as it will always be strictly less than length.
This example can be replaced with the following construction to reduce gas costs:
for (uint i = 0; i < length; i = unchecked_inc(i)) {
// do something that doesn't change the value of i
}
function unchecked_inc(uint i) returns (uint) {
unchecked {
return i + 1;
}
}
For more information, consult the following resources:
nibbl-smartcontracts/contracts/Basket.sol:43: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/Basket.sol:70: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/Basket.sol:93: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:506: for (uint256 i = 0; i < _assetAddresses.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:525: for (uint256 i = 0; i < _assets.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:547: for (uint256 i = 0; i < _assets.length; i++) {
Replace postfix increment (var++) with prefix increment (++var)
Using ++i costs less gas than using i++. In the context of a for-loop, gas is saved on each iteration.
The following lines of code are affected:
nibbl-smartcontracts/contracts/Basket.sol:43: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/Basket.sol:70: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/Basket.sol:93: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:506: for (uint256 i = 0; i < _assetAddresses.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:525: for (uint256 i = 0; i < _assets.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:547: for (uint256 i = 0; i < _assets.length; i++) {
Array length can be cached
In the context of a for-loop that iterates over an array, it costs less gas to cache the array's length in a variable and read from this variable rather than use the arrays .length property. Reading the .length property for on the array will cause a recalculation of the array's length on each iteration of the loop which is a more expensive operation than reading from a stack variable.
For example, the following code:
for (uint i; i < arr.length; ++i) {
// ...
}
should be changed to:
uint length = arr.length;
for (uint i; i < length; ++i) {
// ...
}
Note that in the second case, the length of the array must not change during the loop's execution.
nibbl-smartcontracts/contracts/Basket.sol:43: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/Basket.sol:70: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/Basket.sol:93: for (uint256 i = 0; i < _tokens.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:506: for (uint256 i = 0; i < _assetAddresses.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:525: for (uint256 i = 0; i < _assets.length; i++) {
nibbl-smartcontracts/contracts/NibblVault.sol:547: for (uint256 i = 0; i < _assets.length; i++) {
"calldata" can be used instead of "memory" to reduce gas costs
Both memory and calldata allow a developer to manage variables within the scope of a function. memory is mutable which makes it a more flexible tool; however, it costs additional gas when compared with calldata. calldata is non-modifiable but cheaper. Therefore it is recommended to use calldata for function parameters when they will not be modified.
The following function calls can be changed to use calldata instead of memory:
nibbl-smartcontracts/contracts/Basket.sol:109: function onERC1155BatchReceived(address, address from, uint256[] memory ids, uint256[] memory amounts, bytes memory) external vi
rtual override returns (bytes4) {
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:80: function createBasket(address _curator, string memory _mix) public override returns(address) {
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:88: function getBasketAddress(address _curator, string memory _mix) public override view returns(address _basket) {
Use strict less-than/greather-than comparisons rather than less-than-or-equal/greater-than-or-equal
When compiled, Solidity code using the >= or <= comparison operators in fact executes two separate checks: one for 'is-equal-to' and a second for 'is-greater-than/is-less-than'. By contrast, using > or < performs only one check. Therefore code that is written to use strict comparison operators is more gas-efficient.
If this change is applied, be sure to update the relevant variables being evaluated. For clarity, it is also advised to rename the variables to make this change explicit, e.g. renaming a variable from MINIMUM to MINIMUM_PLUS_ONE.
The following lines are affected:
nibbl-smartcontracts/contracts/NibblVault.sol:147: require(buyoutEndTime <= block.timestamp, "NibblVault: buyoutEndTime <= now");
nibbl-smartcontracts/contracts/NibblVault.sol:184: require(_secondaryReserveRatio <= primaryReserveRatio, "NibblVault: Excess initial funds");
nibbl-smartcontracts/contracts/NibblVault.sol:185: require(_secondaryReserveRatio >= MIN_SECONDARY_RESERVE_RATIO, "NibblVault: secResRatio too low");
nibbl-smartcontracts/contracts/NibblVault.sol:224: _feeCurve = _maxSecondaryBalanceIncrease > _feeCurve ? _feeCurve : _maxSecondaryBalanceIncrease; // the curve fee is cap
ped so that secondaryReserveBalance <= fictitiousPrimaryReserveBalance
nibbl-smartcontracts/contracts/NibblVault.sol:311: if (_totalSupply >= _initialTokenSupply) {
nibbl-smartcontracts/contracts/NibblVault.sol:315: if (_lowerCurveDiff >= msg.value) {
nibbl-smartcontracts/contracts/NibblVault.sol:325: require(_minAmtOut <= _purchaseReturn, "NibblVault: Return too low");
nibbl-smartcontracts/contracts/NibblVault.sol:351: require(_secondaryReserveBalance - _saleReturn >= MIN_SECONDARY_RESERVE_BALANCE, "NibblVault: Excess sell");
nibbl-smartcontracts/contracts/NibblVault.sol:374: if ((_initialTokenSupply + _amtIn) <= _totalSupply) {
nibbl-smartcontracts/contracts/NibblVault.sol:387: require(_saleReturn >= _minAmtOut, "NibblVault: Return too low");
nibbl-smartcontracts/contracts/NibblVault.sol:397: /// Buyout is initiated only when total bid amount >= currentValuation but extra funds over currentValuation are sent back t
o bidder.
nibbl-smartcontracts/contracts/NibblVault.sol:399: require(block.timestamp >= minBuyoutTime, "NibblVault: minBuyoutTime < now");
nibbl-smartcontracts/contracts/NibblVault.sol:404: require(_buyoutBid >= _currentValuation, "NibblVault: Bid too low");
nibbl-smartcontracts/contracts/NibblVault.sol:426: if (_twav >= buyoutRejectionValuation) {
nibbl-smartcontracts/contracts/NibblVault.sol:561: require(block.timestamp <= deadline, "NibblVault: expired deadline");
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:107: require(basketUpdateTime != 0 && block.timestamp >= basketUpdateTime, "NibblVaultFactory: UPDATE_TIME has not pas
sed");
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:131: require(feeToUpdateTime != 0 && block.timestamp >= feeToUpdateTime, "NibblVaultFactory: UPDATE_TIME has not passe
d");
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:141: require(_newFee <= MAX_ADMIN_FEE, "NibblVaultFactory: Fee value greater than MAX_ADMIN_FEE");
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:149: require(feeAdminUpdateTime != 0 && block.timestamp >= feeAdminUpdateTime, "NibblVaultFactory: UPDATE_TIME has not
passed");
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:166: require(vaultUpdateTime != 0 && block.timestamp >= vaultUpdateTime, "NibblVaultFactory: UPDATE_TIME has not passe
d");
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:48: require(msg.value >= MIN_INITIAL_RESERVE_BALANCE, "NibblVaultFactory: Initial reserve balance too low");
Split require() statements using && into separate calls
Using && operations within require() statements increases gas costs. Separate these conditions into separate require() calls.
The following require() statements should be refactored:
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:107: require(basketUpdateTime != 0 && block.timestamp >= basketUpdateTime, "NibblVaultFactory: UPDATE_TIME has not pas
sed");
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:131: require(feeToUpdateTime != 0 && block.timestamp >= feeToUpdateTime, "NibblVaultFactory: UPDATE_TIME has not passe
d"); nibbl-smartcontracts/contracts/NibblVaultFactory.sol:149: require(feeAdminUpdateTime != 0 && block.timestamp >= feeAdminUpdateTime, "NibblVaultFactory: UPDATE_TIME has not
passed");
nibbl-smartcontracts/contracts/NibblVaultFactory.sol:166: require(vaultUpdateTime != 0 && block.timestamp >= vaultUpdateTime, "NibblVaultFactory: UPDATE_TIME has not passe
d");
Pragma statement should be at least 0.8.4
The pragma declaration allows for Solidity versions less than version 0.8.4. Several gas optimization features have been introduced in versions of Solidity between 0.8.0 and 0.8.4, including:
The "low-level inliner" (version 0.8.2)
Improvements to the optimizer (version 0.8.3)
Custom errors (version 0.8.4)
Please note that Solidity version 0.8.9 contains bugfixes in addition to these gas improvements and that if possible it is advised to use versions greater than or equal to 0.8.9 for additional benefit.
For more information consult the following resources:
Gas Report
Variables do not need to be initialized with 'empty' values such as 0, false, or address(0)
Uninitialized variables by default contain a value equivalent to 0:
uints are initialized to 0;bools to false;addresses toaddress(0).Explicitly assigning these values to variables when they are declared increases gas costs while providing no funciton.
e.g. change this code:
uint256 var = 0;to
uint256 var;For more information, please consult the following resources:
Tips and Tricks to Save Gas and Reduce Bytecode Size
The following lines of code are affected:
Unchecked increment can be used in for-loop
Newer versions of the Solidity compiler will check for integer overflows and underflows automatically. This provides safety but increases gas costs.
When an unsigned integer is guaranteed to never overflow, the
uncheckedfeature of Solidity can be used to save gas costs.A common case for this is for-loops using a strictly-less-than comparision in their conditional statement, e.g.:
In cases like this, the maximum value for
lengthis2**256 - 1. Therefore, the maximum value ofiis2**256 - 2as it will always be strictly less thanlength.This example can be replaced with the following construction to reduce gas costs:
For more information, consult the following resources:
Solidity gas optimizations
Solidity docs: underflows, overflows, and unchecked
The following lines of code are affected:
Replace postfix increment (var++) with prefix increment (++var)
Using
++icosts less gas than usingi++. In the context of a for-loop, gas is saved on each iteration.The following lines of code are affected:
Array length can be cached
In the context of a for-loop that iterates over an array, it costs less gas to cache the array's length in a variable and read from this variable rather than use the arrays
.lengthproperty. Reading the.lengthproperty for on the array will cause a recalculation of the array's length on each iteration of the loop which is a more expensive operation than reading from a stack variable.For example, the following code:
should be changed to:
Note that in the second case, the length of the array must not change during the loop's execution.
For more information, see the following resource:
Solidity gas optimizations
The following lines of code are affected:
"calldata" can be used instead of "memory" to reduce gas costs
Both
memoryandcalldataallow a developer to manage variables within the scope of a function.memoryis mutable which makes it a more flexible tool; however, it costs additional gas when compared withcalldata.calldatais non-modifiable but cheaper. Therefore it is recommended to usecalldatafor function parameters when they will not be modified.For more information, see the following resources: Solidity Documentation recommending the use of calldata
Solidity — Storage vs Memory vs Calldata
The following function calls can be changed to use
calldatainstead ofmemory:Use strict less-than/greather-than comparisons rather than less-than-or-equal/greater-than-or-equal
When compiled, Solidity code using the
>=or<=comparison operators in fact executes two separate checks: one for 'is-equal-to' and a second for 'is-greater-than/is-less-than'. By contrast, using>or<performs only one check. Therefore code that is written to use strict comparison operators is more gas-efficient.If this change is applied, be sure to update the relevant variables being evaluated. For clarity, it is also advised to rename the variables to make this change explicit, e.g. renaming a variable from
MINIMUMtoMINIMUM_PLUS_ONE.The following lines are affected:
Split require() statements using && into separate calls
Using
&&operations withinrequire()statements increases gas costs. Separate these conditions into separaterequire()calls.The following
require()statements should be refactored:Pragma statement should be at least 0.8.4
The pragma declaration allows for Solidity versions less than version 0.8.4. Several gas optimization features have been introduced in versions of Solidity between 0.8.0 and 0.8.4, including:
Please note that Solidity version 0.8.9 contains bugfixes in addition to these gas improvements and that if possible it is advised to use versions greater than or equal to 0.8.9 for additional benefit.
For more information consult the following resources:
The following pragma statements should be updated: