Seaport: integration nuance

Reading reports from various contest platforms I noticed there are so many bugs in protocols that were planned to be integrated with other ones. So I thought it'd be useful to make a series of posts about the nuances of integration with different projects, like SeaPort for today.

Seaport is a marketplace protocol for safely and efficiently buying and selling NFTs on the blockchain. Each Seaport order has many components, but we'll first discuss the: the offer and the consideration.

offer: what I am willing to give up (ETH / ERC20 / ERC721 / ERC1155).

The address and the identifierOrCriteria represent which token is being offered (in this case, WETH), and the startAmount and endAmount represent how much of that token you're willing to pay.

consideration: what is required in return (ETH / same ERC)

The address is the address of the Cool Cats NFT contract, the identifierOrCriteria is 1 because we want the NFT with tokenId 1, and the startAmount and endAmount are also 1 because we are offering for a single NFT

If you place this offer through the OpenSea website, OpenSea generates a Seaport order with those offer and consideration structs (and a bunch more info). OpenSea asks you to sign the order, and when you do, the order is submitted to the Seaport contract directly.

On the previous screen you should notice that offer and consideration options are arrays.

The consideration contains an array of items that must be received in order to fulfill the order. It contains all of the same components as an offered item, and additionally includes a recipient that will receive each item. This array may be extended by the fulfiller on order fulfillment so as to support "tipping" (e.g. relayer or referral payments).

Here what it means:

Auditing Tip: Whenever you are looking for bugs in a protocol that integrates with Seaport, you should check if a hacker can add a malicious token to the consideration array.

Also check if consideration array has the same size at different order timepoints.