Nested Finance contest - rfa's results

The one-stop Defi app to build, manage and monetize your portfolio.

General Information

Platform: Code4rena

Start Date: 10/02/2022

Pot Size: $30,000 USDC

Total HM: 5

Participants: 24

Period: 3 days

Judge: harleythedog

Total Solo HM: 3

Id: 86

League: ETH

Nested Finance

Findings Distribution

Researcher Performance

Rank: 14/24

Findings: 2

Award: $195.39

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: pauliax

Also found by: 0xliumin, Dravee, GreyArt, IllIllI, Omik, ShippooorDAO, WatchPug, bobi, csanuragjain, gzeon, kenzo, rfa, robee, samruna

Labels

bug
QA (Quality Assurance)
sponsor confirmed

Awards

105.3884 USDC - $105.39

External Links

-check _metadataURI !="" https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedAsset.sol#L106 backfillTokenURI() & mintWithMetadatawas expected to change tokenURI. By not validating metadataURI!= "", it will just spend user gas more and nothing was changed

#0 - maximebrugel

2022-02-15T14:49:08Z

Also, it's better to not let the sender removing the URI

#1 - harleythedogC4

2022-03-01T02:18:22Z

My personal judgements:

  1. "check _metadataURI !=""". The user is able to remove the URI after it has been set. Valid and very-low-critical.

#2 - harleythedogC4

2022-03-03T02:26:44Z

Now, here is the methodology I used for calculating a score for each QA report. I first assigned each submission to be either non-critical (1 point), very-low-critical (5 points) or low-critical (10 points), depending on how severe/useful the issue is. The score of a QA report is the sum of these points, divided by the maximum number of points achieved by a QA report. This maximum number was 26 points, achieved by https://github.com/code-423n4/2022-02-nested-findings/issues/66.

The number of points achieved by this report is 5 points. Thus the final score of this QA report is (5/26)*100 = 19.

Findings Information

Awards

90.0012 USDC - $90.00

Labels

bug
duplicate
G (Gas Optimization)

External Links

##NestedFinanceGasFindings 1-- -using multiple require() is gas saving https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L54-L62 instead of using &&, using multiple require is gas saving.

require(address(_nestedAsset) != address(0)); require(address(_nestedRecords) != address(0)); ...

2-- -better for() implementation https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L113 replace i++ to ++i and dont set the i value because the default is already 0. Its cost less gas usage

for (uint256 i; i < operatorsLength; ++i)

3-- -Better way of using SafeERC20 lib https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L19 By calling SafeERC20.function directly and removing line 19 can save 15 gas per call:

SafeERC20.safeTransfer(_token, owner(), amount);

SafeErc20.function was called 8 times in this contract. Also very good to implemented at NestedReserve.sol 4-- -using storage instead of caching struct/array data can save gas https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L205 using storage can save gas

address[] storage tokens = nestedRecords.getAssetTokens(_nftId);

tokens is called once at destroy() before it chaced to tokensLength as tokens.lenght so reading from storage is cheaper than using memory 5-- -use calldata to store _weights & _account https://github.com/code-423n4/2022-02-nested/blob/main/contracts/FeeSplitter.sol#L89-L90 change memory to calldata

#0 - maximebrugel

2022-02-17T14:23:43Z

1 (Disputed)

Not the case. From 4966507 to 4970427

2 (Disputed)

Already in first audit : https://github.com/code-423n4/2021-11-nested-findings/issues/25

3 (Duplicated)

https://github.com/code-423n4/2022-02-nested-findings/issues/55

4 (Disputed)

Compilation error address[] storage tokens = nestedRecords.getAssetTokens(_nftId); you can't convert to storage like this.

5 (Disputed)

Data location must be "storage" or "memory" for constructor parameter.

#1 - harleythedogC4

2022-03-09T04:17:29Z

My personal judgements:

  1. "using multiple require() is gas saving". This was confirmed by the sponsor in #55, so it should be valid here too (although it is a very small difference in gas). Valid and small optimization.
  2. "better for() implementation". Agree with sponsor. Invalid.
  3. "Better way of using SafeERC20 lib". Valid and small optimization.
  4. "using storage instead of caching struct/array data can save gas". Example gives compilation error, Invalid.
  5. "use calldata to store _weights & _account". As sponsor says. Invalid.

#2 - harleythedogC4

2022-03-13T06:18:14Z

Now, here is the methodology I used for calculating a score for each gas report. I first assigned each submission to be either small-optimization (1 point), medium-optimization (5 points) or large-optimization (10 points), depending on how useful the optimization is. The score of a gas report is the sum of these points, divided by the maximum number of points achieved by a gas report. This maximum number was 10 points, achieved by #67.

The number of points achieved by this report is 2 points. Thus the final score of this gas report is (2/10)*100 = 20.

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