OpenSea Seaport 1.2 contest - delfin454000's results

A marketplace protocol for safely and efficiently buying and selling NFTs.

General Information

Platform: Code4rena

Start Date: 13/01/2023

Pot Size: $100,500 USDC

Total HM: 1

Participants: 23

Period: 10 days

Judge: hickuphh3

Total Solo HM: 1

Id: 201

League: ETH

OpenSea

Findings Distribution

Researcher Performance

Rank: 15/23

Findings: 1

Award: $140.67

QA:
grade-b

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

Awards

140.6728 USDC - $140.67

Labels

bug
grade-b
QA (Quality Assurance)
Q-01

External Links

Summary

Non-critical findings

IssueDescriptionInstances
1Named return variables are not used when a function returns1
2Duplicate code1
3Long indentation within some Natspec statements reduces readability3 + multiple
4@param statements are missing for structs1 + multiple
5Typos1
6pragma solidity version should be upgraded to latest version before finalization1
Total8 + multiple
No.Description
1Named return variables are not used when a function returns
Below, none of the four named return variables is ever used

OrderValidator.sol: L828-838

    function _getOrderStatus(
        bytes32 orderHash
    )
        internal
        view
        returns (
            bool isValidated,
            bool isCancelled,
            uint256 totalFilled,
            uint256 totalSize
        )

No.Description
2Duplicate code
Large sections of identical code are repeated in two different interface contracts, as shown below:

ConsiderationInterface: L107-458

is identical to

SeaportInterface: L106-457


No.Description
3Long indentation within some Natspec statements reduces readability
While the choice of comment spacing is up to the developers, it should be made consistent throughout. Four spaces is a commonly used unit of indentation. However, when @param, @custom:param or @return statements wrap within Opensea Seaport, the indentation after the first line often is very large, as much as 20 spaces.

Below is an example of the appropriate spacing of @dev statements used throughout the contest. @notice statements also normally have similar suitable spacing.

PointerLibraries.sol: L75-77

    /// @dev Resolves an offset stored at `cdPtr + headOffset` to a calldata.
    ///      pointer `cdPtr` must point to some parent object with a dynamic
    ///      type's head stored at `cdPtr + headOffset`.

On the other hand, as the examples below show, @param, @custom:param and @return statements tend to have extra-wide spacing when they wrap. This should be corrected.


Consideration.sol: L236-240

     * @custom:param considerationFulfillments An array of FulfillmentComponent
     *                                         arrays indicating which
     *                                         consideration items to attempt to
     *                                         aggregate when preparing
     *                                         executions.

Consideration.sol: L373-376

     * @param recipient                        The intended recipient for all
     *                                         received items, with `address(0)`
     *                                         indicating that the caller should
     *                                         receive the offer items.

ConsiderationDecoder.sol: L28-32

     * @param cdPtrLength A calldata pointer to the start of the bytes array in
     *                    calldata which contains the length of the array.
     *
     * @return mPtrLength A memory pointer to the start of the bytes array in
     *                    memory which contains the length of the array.

No.Description
4@param statements are missing for structs
The structs in ConsiderationStructs.sol are preceded by @dev statements with extensive commentary, as shown below. These contain information that could fairly easily be converted into @param statements. This would have the advantage of conforming to Natspec guidelines and standardizing the descriptions of the struct variables.

ConsiderationStructs.sol: L16-38

/**
 * @dev An order contains eleven components: an offerer, a zone (or account that
 *      can cancel the order or restrict who can fulfill the order depending on
 *      the type), the order type (specifying partial fill support as well as
 *      restricted order status), the start and end time, a hash that will be
 *      provided to the zone when validating restricted orders, a salt, a key
 *      corresponding to a given conduit, a counter, and an arbitrary number of
 *      offer items that can be spent along with consideration items that must
 *      be received by their respective recipient.
 */
struct OrderComponents {
    address offerer;
    address zone;
    OfferItem[] offer;
    ConsiderationItem[] consideration;
    OrderType orderType;
    uint256 startTime;
    uint256 endTime;
    bytes32 zoneHash;
    uint256 salt;
    bytes32 conduitKey;
    uint256 counter;
}

No.Description
5Typos

TypehashDirectory.sol: L31

        // Declare an array where each type hash will be writter.

Change writter to writer


No.Description
6pragma solidity version should be upgraded to latest version before finalization
About 40% of the in-scope contracts use the latest solidity version, pragma solidity ^0.8.17. The remainder use ^0.8.13, as shown below, and should be upgraded before implementation. Only the latest version receives security fixes.

ConsiderationEncoder.sol: L2

pragma solidity ^0.8.13;


#0 - c4-judge

2023-01-26T02:47:07Z

HickupHH3 marked the issue as grade-b

#1 - HickupHH3

2023-01-26T02:47:50Z

5 NCs (disagree with the last as it's for reference contracts).

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