ERC4626Transformer Code Style Findings

ERC-01C: Ineffectual Usage of Safe Arithmetics

Type	Severity	Location
Language Specific		ERC4626Transformer.sol:L108

Description:

The linked mathematical operation is guaranteed to be performed safely by surrounding conditionals evaluated in either require checks or if-else constructs.

Example:

Copy
106if (_spentUnderlying < _neededUnderlying) {
107  _underlying.safeTransfer(msg.sender, _neededUnderlying - _spentUnderlying);
108}

Recommendation:

Given that safe arithmetics are toggled on by default in pragma versions of 0.8.X, we advise the linked statement to be wrapped in an unchecked code block thereby optimizing its execution cost.

Alleviation (6ed56b5449ca241fc6be369d44f392f1f5313f93):

An unchecked directive was introduced wrapping the referenced mathematical operation and optimizing the statement's gas cost.

ERC-02C: Misleading Naming Conventions

Type	Severity	Location
Code Style		ERC4626Transformer.sol:L112-L115, L117-L120

Description:

The functions _toUnderlying & _toUnderlyingAmount simply assign an input address / uint256 to a single-entry address / uint256 array and yield it.

Example:

Copy
112function _toUnderlying(address _underlying) internal pure returns (address[] memory _underlyingArray) {
113  _underlyingArray = new address[](1);
114  _underlyingArray[0] = _underlying;
115}

Recommendation:

We advise them to be renamed to _toSingletonArray instead as the _toUnderlying / _toUnderylingAmount function names signify additional logic that would somehow convert the _underlying / _amount data points which doesn't exist.

Alleviation (6ed56b5449ca241fc6be369d44f392f1f5313f93):

The _toUnderlying and _toUnderlyingAmount functions were both updated to _toSingletonArray increasing the legibility of the codebase significantly.