Omniscia Gnosis Guild Audit
MultiSendUnwrapper Code Style Findings
MultiSendUnwrapper Code Style Findings
MSU-01C: Deprecated if-revert Pattern
| Type | Severity | Location |
|---|---|---|
| Code Style | ![]() | MultiSendUnwrapper.sol:L16-L17, L19-L20, L29-L30, L35-L36 |
Description:
The referenced statements utilize the if-revert pattern without any custom error messages.
Example:
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
| Type | Severity | Location |
|---|---|---|
| Code Style | ![]() | MultiSendUnwrapper.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:
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.
