Frax Ether Liquid Staking contest - Tomio's results

Title: Gas savings for using solidity 0.8.10

Proof of Concept: All contract in scope

Recommended Mitigation Steps: Consider to upgrade pragma to at least 0.8.10.

Solidity 0.8.10 has a useful change which reduced gas costs of external calls Reference: here

---

Title: Boolean comparison

Proof of Concept: ERC20PermitPermissionedMint.sol#L46 ERC20PermitPermissionedMint.sol#L68 ERC20PermitPermissionedMint.sol#L78

Recommended Mitigation Steps: I suggest using require(minters[minter_address], "Address nonexistant"); or require(!minters[minter_address], "Address already exists"); instead of require(minters[minter_address] == true, "Address nonexistant"); or require(minters[minter_address] == false, "Address already exists");

---

Title: Reduce the size of error messages (Long revert Strings)

Impact: Shortening revert strings to fit in 32 bytes will decrease deployment time gas and will decrease runtime gas when the revert condition is met. Revert strings that are longer than 32 bytes require at least one additional mstore, along with additional overhead for computing memory offset, etc.

Proof of Concept: frxETHMinter.sol#L167

Recommended Mitigation Steps: Consider shortening the revert strings to fit in 32 bytes

---

Title: Custom errors from Solidity 0.8.4 are cheaper than revert strings

Impact: Custom errors from Solidity 0.8.4 are cheaper than revert strings (cheaper deployment cost and runtime cost when the revert condition is met) while providing the same amount of information

Custom errors are defined using the error statement reference: https://blog.soliditylang.org/2021/04/21/custom-errors/

Proof of Concept: ERC20PermitPermissionedMint.sol (various line) frxETHMinter.sol (various line)

Recommended Mitigation Steps: Replace require statements with custom errors.

---

Title: Using != in require statement is more gas efficient

Proof of Concept: frxETHMinter.sol#L79 frxETHMinter.sol#L126

Recommended Mitigation Steps: Change > 0 to != 0

---

Title: Default value initialization

Impact: If a variable is not set/initialized, it is assumed to have the default value (0, false, 0x0 etc depending on the data type). Explicitly initializing it with its default value is an anti-pattern and wastes gas.

Proof of Concept: ERC20PermitPermissionedMint.sol#L84 frxETHMinter.sol#L94 frxETHMinter.sol#L129 OperatorRegistry.sol#L63 OperatorRegistry.sol#L84 OperatorRegistry.sol#L114

Recommended Mitigation Steps: Remove explicit initialization for default values.

---

Title: Consider make constant as private to save gas

Proof of Concept: frxETHMinter.sol#L38-L39

Recommended Mitigation Steps: I suggest changing the visibility from public to internal or private

---

Title: Unchecking arithmetics operations that can't underflow/overflow

Proof of Concept: frxETHMinter.sol#L168 Should be unchecked due to L#167

Recommended Mitigation Steps: Use unchecked

---

Title: Set as immutable can save gas

Proof of Concept: OperatorRegistry.sol#L38

Recommended Mitigation Steps: can be set as immutable, which already set once in the constructor

---

Title: Using unchecked and prefix increment is more effective for gas saving:

Proof of Concept: OperatorRegistry.sol#L63 OperatorRegistry.sol#L84 OperatorRegistry.sol#L114

Recommended Mitigation Steps: Change to:

    for (uint256 i = 0; i < arrayLength;) {
    // ...
    unchecked { ++i; }
    }

---

Title: Usage of uints/ints smaller than 32 bytes (256 bits) incurs overhead

Impact: 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.

Reference: Here

Proof of Concept: xERC4626.sol#L24-L30

---