Nouns DAO contest - ReyAdmirado's results

A DAO-driven NFT project on Ethereum.

General Information

Platform: Code4rena

Start Date: 22/08/2022

Pot Size: $50,000 USDC

Total HM: 4

Participants: 160

Period: 5 days

Judge: gzeon

Total Solo HM: 2

Id: 155

League: ETH

Nouns DAO

Findings Distribution

Researcher Performance

Rank: 37/160

Findings: 2

Award: $54.67

🌟 Selected for report: 0

🚀 Solo Findings: 0

1. typo in comments

setable --> settable

contructor --> constructor

priviledges --> privileges

GovernerBravo --> GovernorBravo

2. use of floating pragma

Contracts should be deployed with the same compiler version and flags that they have been tested with thoroughly. Locking the pragma helps to ensure that contracts do not accidentally get deployed using, for example, an outdated compiler version that might introduce bugs that affect the contract system negatively.

3. event is missing indexed fields

Each event should use three indexed fields if there are three or more fields

4. constants should be defined rather than using magic numbers

Even assembly can benefit from using readable constants instead of hex/numeric literals

5. inconsistency in comments

should have one *

in other parts of the code there is no blank space

6. lines are too long

Usually lines in source code are limited to 80 characters. Today’s screens are much larger so it’s reasonable to stretch this in some cases. Since the files will most likely reside in GitHub, and GitHub starts using a scroll bar in all cases when the length is over 164 characters, the lines below should be split when they reach that length

7. Outdated compiler version

Using very old versions of Solidity prevents benefits of bug fixes and newer security checks. Using the latest versions might make contracts susceptible to undiscovered compiler bugs

1. expressions for constant values such as a call to keccak256(), should use immutable rather than constant

2. using argument instead of StateVar saves gas

use newVotingDelay instead of votingDelay in this line can save gas

use newVotingPeriod instead of votingPeriod in this line can save gas

use newProposalThresholdBPS instead of proposalThresholdBPS in this line can save gas

use newQuorumVotesBPS instead of quorumVotesBPS in this line can save gas

use newVotingDelay instead of votingDelay in this line can save gas

use newVotingPeriod instead of votingPeriod in this line can save gas

use newProposalThresholdBPS instead of proposalThresholdBPS in this line can save gas

use implementation_ instead of implementation in this line can save gas

3. use stack variables instead of state variables

use oldPendingAdmin instead of pendingAdmin in this line can save gas

use oldPendingAdmin instead of admin in this line can save gas

use oldPendingAdmin instead of pendingAdmin in this line can save gas

use oldPendingAdmin instead of admin in this line can save gas

4. state variables should be cached in stack variables rather than re-reading them from storage

before line 227 proposalCount should be cached, and it can be used in line 247 instead of newProposal.id to save gas:

5. not using the named return variables when a function returns, wastes deployment gas

6. <array>.length should not be looked up in every loop of a for-loop

This reduce gas cost as show here https://forum.openzeppelin.com/t/a-collection-of-gas-optimisation-tricks/19966/5

7. ++i costs less gas than i++, especially when it’s used in for-loops (--i/i-- too)

8. it costs more gas to initialize non-constant/non-immutable variables to zero than to let the default of zero be applied

9. ++i/i++ should be unchecked{++i}/unchecked{i++} when it is not possible for them to overflow, as is the case when used in for-loop and while-loops

10. require()/revert() strings longer than 32 bytes cost extra gas

11. splitting require() statements that use && saves gas

12. use custom errors rather than revert()/require() strings to save deployment gas

https://blog.soliditylang.org/2021/04/21/custom-errors/

13. use a more recent version of solidity

Use a solidity version of at least 0.8.10 to have external calls skip contract existence checks if the external call has a return value Use a solidity version of at least 0.8.13 to get the ability to use using for with a list of free functions

and for ERC721Enumerable.sol file:

Use a solidity version of at least 0.8.2 to get compiler automatic inlining Use a solidity version of at least 0.8.3 to get better struct packing and cheaper multiple storage reads Use a solidity version of at least 0.8.4 to get custom errors, which are cheaper at deployment than revert()/require() strings

14. using bools for storage incurs overhead

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/58f635312aa21f947cae5f8578638a85aa2519f5/contracts/security/ReentrancyGuard.sol#L23-L27

15. internal functions only called once can be inlined to save gas

Not inlining costs 20 to 40 gas because of two extra JUMP instructions and additional stack operations needed for function calls.

16. abi.encode() is less efficient than abi.encodepacked()

17. usage of uint/int smaller than 32 bytes (256 bits) incurs overhead

When using elements that are smaller than 32 bytes, your contract’s gas usage may be higher. This is because the EVM operates on 32 bytes at a time. Therefore, if the element is smaller than that, the EVM must use more operations in order to reduce the size of the element from 32 bytes to the desired size. https://docs.soliditylang.org/en/v0.8.11/internals/layout_in_storage.html Use a larger size then downcast where needed

18. using private rather than public for constants, saves gas

If needed, the values can be read from the verified contract source code, or if there are multiple values there can be a single getter function that returns a tuple of the values of all currently-public constants. Saves 3406-3606 gas in deployment gas due to the compiler not having to create non-payable getter functions for deployment calldata, not having to store the bytes of the value outside of where it’s used, and not adding another entry to the method ID table

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter