Omniscia Gnosis Guild Audit

MultiSendUnwrapper Code Style Findings

MultiSendUnwrapper Code Style Findings

MSU-01C: Deprecated if-revert Pattern

TypeSeverityLocation
Code StyleMultiSendUnwrapper.sol:L16-L17, L19-L20, L29-L30, L35-L36

Description:

The referenced statements utilize the if-revert pattern without any custom error messages.

Example:

packages/evm/contracts/adapters/MultiSendUnwrapper.sol
16if (value != 0) {
17 revert();
18}
19if (operation != Enum.Operation.DelegateCall) {
20 revert();
21}

Recommendation:

We advise either custom error messages to be defined for the referenced failure cases or the statement blocks to be replaced by require statements with a descriptive error message, either of which we consider an adequate resolution to this exhibit.

Alleviation:

All revert statements in the codebase have been updated to yield one of the three newly declared custom errors in the MultiSendUnwrapper contract, standardizing the code's style and enhancing its debugging capabilities.

MSU-02C: Non-Standard Definition of Function Signature

TypeSeverityLocation
Code StyleMultiSendUnwrapper.sol:L7

Description:

The referenced bytes4 literal is meant to represent the function signature of multiSend(bytes), however, it is defined in its literal format.

Example:

packages/evm/contracts/adapters/MultiSendUnwrapper.sol
7bytes4 private constant SELECTOR = 0x8d80ff0a;

Recommendation:

We advise an interface to be defined that represents the IMultiSend contract with the correct function signature. Consequently, the function signature's selector can be accessed via the homonym syntax (i.e. IMultiSend.multiSend.selector) greatly optimizing the code's legibility.

Alleviation:

Our recommendation was applied to the letter, declaring an IMultiSend interface in Types and utilizing the selector syntax in place of a function signature literal where SELECTOR was utilized.