Fraxlend (Frax Finance) contest - ReyAdmirado's results

Fraxlend: A permissionless lending platform and the final piece of the Frax Finance Defi Trinity.

General Information

Platform: Code4rena

Start Date: 12/08/2022

Pot Size: $50,000 USDC

Total HM: 15

Participants: 120

Period: 5 days

Judge: Justin Goro

Total Solo HM: 6

Id: 153

League: ETH

Frax Finance

Findings Distribution

Researcher Performance

Rank: 39/120

Findings: 2

Award: $69.32

๐ŸŒŸ Selected for report: 0

๐Ÿš€ Solo Findings: 0

1. 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.

2. typo in comments

toBorrtoBorrowAmountowShares --> toBorrowAmount

whos -- whom

approcal --> approval

accomodate --> accommodate

FraxLedWhitelist --> FraxLendWhitelist

whitlist --> whitelist

occured --> occurred

liabilites --> liabilities

Calced --> Calculated

stuct --> struct

oralce --> oracle

3. event is missing indexed fields

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

4. _safemint() should be used rather than _mint() wherever possible

5. constants should be defined rather than using magic numbers

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

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

1. state variables only set in the constructor should be declared immutable

avoids a gsset (20000 gas)

2. <x> += <y> costs more gas than <x> = <x> + <y> for state variables

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

4. <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 1- if it is a storage array, this is an extra sload operation (100 additional extra gas (EIP-2929 2) for each iteration except for the first), 2- if it is a memory array, this is an extra mload operation (3 additional gas for each iteration except for the first), 3- if it is a calldata array, this is an extra calldataload operation (3 additional gas for each iteration except for the first)

5. ++i costs less gas than i++, especially when itโ€™s used in for-loops (--i/i-- too)

Saves 6 gas per loop

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

7. ++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

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

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

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

10. using calldata instead of memory for read-only arguments in external functions saves gas

11. using bools for storage incurs overhead

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/58f635312aa21f947cae5f8578638a85aa2519f5/contracts/security/ReentrancyGuard.sol#L23-L27 Use uint256(1) and uint256(2) for true/false to avoid a Gwarmaccess (100 gas) for the extra SLOAD, and to avoid Gsset (20000 gas) when changing from โ€˜falseโ€™ to โ€˜trueโ€™, after having been โ€˜trueโ€™ in the past

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

13. 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

14. using > 0 costs more gas than != 0 when used on a uint in a require() statement

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

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