Basic orders where the offerer supplies some ERC20 item type and also specifies that same item type as additional consideration items will transfer the item directly from the offerer to the additional recipients as an efficiency hack (preventing the fulfiller from needing to hold or approve that item).

In these cases, ensure that the sum total of additional consideration items does not exceed the offered amount, as otherwise the offerer may end up spending more than the offered amount!

There is only one instance of a loop where i++ is used instead of ++i. Unless there is a specific reason for doing this, consider using ++i for it to be consistent with the rest of the code.

come up with some valid orders for the NonReenrant tests? not the reentrant parts; just the…. entrant parts. right now i just have one fulfillBasicOrder set up

don’t need to fuzz the inputs on the orders, they just need to be constructed and submitted. the ReentrantContract is very similar to the Reenterer where it tries to re-enter on receive

https://github.com/ProjectOpenSea/consideration/blob/e413b0459f43d225639fe70a34e657efae298a2b/test/foundry/utils/reentrancy/ReentrantEnums.sol#L8
we need one of for each of

• FulfillOrder,
• FulfillAdvancedOrder,
• FulfillAvailableOrders,
• FulfillAvailableAdvancedOrders and
• MatchAdvancedOrders

...for NonReentrant.t.sol

Given that we use connect everywhere in hardhat tests to set the caller/sender of a particular transaction, the whileImpersonating blocks are redundant and added significant tech debt.

We should remove all whileImpersonating wrappers

Gas optimization, on OrderFulfiller.sol#L309 you could cache variable orderParameters.offer.length to save gas.

Pull request:
#336

In the _transferETHAndFinalize function is a checked subtraction that reverts when there is less msg.value provided than the sum of amounts of additionalRecipients.

Consider checking that the additional recipient amount does not exceed etherRemaining and otherwise revert with a proper error message.

The ConsiderationPure contract implements the _convertOrdersToAdvanced function which helps in the conversion of regular orders into AdvancedOrders.

However, there are places where this same conversion is done manually inside a function, for instance in the fulfillOrder function from the Consideration contract.

In order to improve the readability of the code and its size, with the possibility of gas cost reduction, consider using the already implemented function when suitable to convert orders into advanced ones.

0xc081d461F18550B4CAf92Be14339A0e1dA29AF9C

The increment on line 788 can be unchecked to save some gas

Hi seaport builders.

Is there any plans to add support for eip-2981 natively within the protocol? I thought it would be supported but I cannot find anything in the docs or implementation code.

It would be an amazing achievement for the ecosystem to get royalties etched into something like this and would help ratify the standard and usage of royalties for all.

If there are not plans to support it I'd be interested to know why not?

The standard -> https://eips.ethereum.org/EIPS/eip-2981 (I am one of the authors and would love to help get this integrated if possible)

Thanks

make 6*8 enum type
keep the same order
add extensions for each possible of:

fulfillBasicEthForERC721Order,
fulfillBasicEthForERC1155Order,
fulfillBasicERC20ForERC721Order,
fulfillBasicERC20ForERC1155Order,
fulfillBasicERC721ForERC20Order,
fulfillBasicERC1155ForERC20Order

Lots of optimization work from transfer functions on Consideration can be adapted to suit this purpose.

Hi, how are seaport collection offers retrieved for a collection via the API?

• The v2.0 API has an offers endpoint, but it seems to require a token ID with the collection address, and only gives offers specific to that token, not returning "collection-wide" offers.
• The v1.1 API has a single asset offers endpoint, and it does return seaport orders, but none are collection offers.

Thank you much. If this is not the right place to ask this, I apologize. I am not a user of discord so this was the only alternative I could find. Please point me somewhere else if that's where I should go.

In createConduit function conduit.codehash == _CONDUIT_RUNTIME_CODE_HASH is used to check the existence of conduit. As the conduit contract is not warmed up EXTCODEHASH would cost 2500 extra cost. As the storage at _conduits[conduit] is anyways updated in future it is better to use _conduits[conduit].key == bytes32(0)(or call function _assertConduitExists). This will give a gas saving of 2500

P.S. In the end conduit contract is warmed up after CREATE2 but the cost of CREATE2 is not reduced if the contract is already warmed up by EXTCODEHASH

Please describe the algorithm of how to create an auction using the seaport protocol

as a user, I want to be able to create a store to sell items at auction
I want to be able to set the start and end time of the auction in the future
I want to be able to set a buyout price that ends the auction immediately

How to create an order with date ranges?
How to create an order which will not be filled after the first bet and will accept another bet with a bigger amount
How to set buyout price which will end auction right after fulfillment
How to call seaport from the server when action timed up but the buyout price was not reached

Foundry tests unusable without the optimized bytecode.
I'd note that something like FOUNDRY_PROFILE=optimized forge test or yarn test:forge needs to be used instead

Use custom error checks in hardhat tests in place of generic revert checks. failures should specify what failed.

The overloaded use of the ternary operator decreases the readability and would better be solved with an if/else statement.
This is the case for the _transferERC20, _transferERC721, and _transferERC1155 function.

Consider using ternary operators for rather short statements or one-liners.

Seaport 1.1 only deploys contracts on Ethereum Mainnet and Rinkeby. Polygon is a popular network and I would like to use Seaport on Polygon.

We need helpers for things like:

• constructing fully-formatted orders from a minimal set of inputs
• retrieving balance and approval information for items on orders (taking conduit information into account)
• signing orders (via 65-byte, 64-byte, and 1271)
• fulfilling orders or groups of orders while ensuring that balance changes, events, and return values are valid
• cancelling orders, validating orders, incrementing nonces
• interacting with zones (deriving zone hashes, routing through zones, etc)

Adapt consideration-js and fuzzing tests to use the new interface (both for the above as well as for the inclusion of zoneHash in order parameters)

Throughout the codebase there are several occurrences of literal values used to compare agains ItemType and OrderType variables. These are some examples:

• Line 102 of ConsiderationInternal.
• Line 254 of ConsiderationInternal.
• Line 178 of ConsiderationPure.
• Line 186 of ConsiderationPure.
• Line 413 of ConsiderationInternalView.

These make the code harder to reason about and the reader must constantly go back to the struct definitions to understand the comparisons being made. To favor readability, consider creating and using simple functions like _isCriteriaBased(ItemType), _usesProxy(OrderType), or similar.

1. what's the meaning for criteria-based or not criteria-based
2. what's the difference between zone and conduit
3. I read through your reference doc many times ，found some about "item" not qualified by "offer" or consideration,so I really don't understand where the item is include in,such as "All other items have the same Ether (or other native tokens) or ERC20 item type and token."
4. so,the repo is just for fulfill an order ,but not including creating an order ?

The hardhat tests currently have 15 test cases that are "pending" — while code coverage is still at 100%, there are more complex combinations of features that are not being tested at the moment.

I was in a team that developed ERC998 standard back in 2018 so I pretend to be a contributor and heavy user of this standard. Yes, it is not so popular because of reasons. One of these reasons marketplaces does not support it. You potentially could become the first one to support it with the new protocol.

Basically, ERC998 utilizes the 4th optional parameter of transferFrom method from ERC721. It would be great if you can add it to OfferItem and ConsiderationItem and default to 0x

In case you are interested let's convert this feature request into discussion and check the pros and cons

The _applyFractionsAndTransferEach calls _applyOfferedFractionAndTransfer which returns the amount transferred. It then checks to see if that amount exceeds the ether remaining and throws a more informative error if so before decrementing the amount. As-is, the error should never be reachable — this should be refactored to perform that error check inside of _applyOfferedFractionAndTransfer instead.

Should just replace this with a plain old description of what's happening

Originally posted by @0age in #489 (comment)

When fulfilling a set of orders via matchOrders or matchAdvancedOrders, executions should not be generated in the event that a particular fulfillment results in the same from and to address (i.e. the same offerer and recipient). By way of example, consider the following:

• Offerer A creates order 1 offering NFT X with amount N as consideration (i.e. to sell NFT X for N)
• Offerer A creates order 2 offering amount N with NFT Y as consideration (i.e. to buy NFT Y for N)
• Offerer B can create order 3 offering NFT Y with NFT X as consideration
• Fulfillments link:
  • order 2 offer and order 1 consideration => no execution required
  • order 1 offer and order 3 consideration => transfer NFT X from offerer A to offerer B
  • order 3 offer and order 2 consideration => transfer NFT Y from offerer B to offerer A

When we go in a multi-chain world, it'll be more confusing when we use the word ETH for the protocol token. More concerned about the confusion for our backend, even though on a contract level it's implied.

When the validate function from the Consideration contract calls the ConsiderationInternalView._getOrderStatusAndVerify internal function, the first check that it does is to assert that it's not cancelled.

Even though more code is executed afterwards, the same check is done lines below in L743 from Consideration.sol with the same data and outcome, being able to be removed.

Furthermore, because the _assertOrderNotCancelled function is only used in those 2 places, consider removing that function and implement it directly into the _getOrderStatusAndVerify function to refactor the code.

Both matchOrders and matchAdvancedOrders functions call the same _matchOrders internal function.

But because this _matchOrders function only calls the _validateOrdersAndApplyPartials function and redirects the flow to the _fulfillOrders function, it could be deleted and instead it could be either being integrated its only call to the _validateOrdersAndApplyPartials function in both matchOrders and matchAdvancedOrders functions or in the _fulfillOrders function, which is only being called once by it.

In line 785 of the Consideration contract, the newNonce is returned. This is not necessary as the named return parameter already contains the value being returned. Consider removing the return statement.

In some test cases there is code duplication:

• Line 1158 and 1169
• Line 1242 and 1253
• Line 1349 and 1360

Do you guys plan to keep this repo in sync with the production code in use at OpenSea?

New assembly sections and wacky casting needs some documentation pretty badly

The current conduit implementation derives the conduit from the key and performs a call to that conduit on each item transfer. These calls should be gathered into an "accumulator" that grows until a non-native item transfer is encountered that does not utilize the same conduit or all item transfers have been processed, at which point the conduit should be called with that entire accumulated set (with a new accumulator created if relevant).

I want to create a listing with the seaport version two api:v2/orders/ethereum/seaport/listings and I have composed the order_parameters parameter:
{
"offerer": "0x88edCa617B8E4fF3793d06F42E5b80225c2f5AdA",
"zone": "0x00000000E88FE2628EbC5DA81d2b3CeaD633E89e",
"zone_hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"start_time": "1655458073",
"end_time": "1658050073",
"order_type": 0,
"salt": "123456",
"conduitKey": "0x0000007b02230091a7ed01230072f7006a004d60a8d4e71d599b8104250f0000",
"nonce": "0",
"offer": [
{
"item_type": 3,
"token": "0x7f04504AE8DB0689A0526d99074149FE6dDf838c",
"identifier_or_criteria": "10",
"startAmount": 1,
"endAmount": 1
}
],
"consideration": [
{
"item_type": 0,
"token": "",
"identifier_or_criteria": "",
"startAmount": 0.5,
"endAmount": 0.5,
"recipient": "0x1f5e0376def810b7a46d72bfb561460bcd686288"
}
]
}

there are two question with me :
first. where I could get or create the signature which this api need
sencode. I just leave the signature blank ,then I push the try button,but the request was always on loading state：

Hey guys, first of all, kudos for open sourcing such a massive protocol!

I want to obtain order hash offline.

Could you help with that ?

Hi guys thanks a lot for outsourcing this massive protocol

as a user, I want to sell items using lazy mint. let's say I have a contract

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";

contract ERC721ACBR is AccessControl, ERC721 {
  bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
  
  constructor(
    string memory name,
    string memory symbol,
  ) ERC721(name, symbol) {
    _setupRole(DEFAULT_ADMIN_ROLE, _msgSender());
    _setupRole(MINTER_ROLE, _msgSender());
 }

  function mint(address to, uint256 tokenId) public virtual onlyRole(MINTER_ROLE) {
    _mint(to, tokenId);
  }
}

now I want to create an order signed by wallet with MINTER_ROLE
that contains an invocation of mint(address, uint256) instead of transfer(address,address,uint256)
to sell the not minted items for a fixed price using seaport

Hello,

We are trying to build this on s390x platform which is a big endian architecture.

I installed yarn and node.js and was able to execute these commands successfully.
yarn install
yarn build

However, yarn test is giving the error saying it expected little endian system.

  hardhat:core:compilation-job File '/data/vishwa/seaport/contracts/conduit/lib/ConduitConstants.sol' will be compiled with version '0.8.14' +1ms
  hardhat:core:hre Running task compile:solidity:handle-compilation-jobs-failures +2ms
  hardhat:core:hre Running task compile:solidity:filter-compilation-jobs +0ms
  hardhat:core:tasks:compile '12' jobs were filtered out +35ms
  hardhat:core:hre Running task compile:solidity:merge-compilation-jobs +5ms
  hardhat:core:hre Running task compile:solidity:compile-jobs +0ms
  hardhat:core:hre Running compile:solidity:compile-jobs's super +0ms
  hardhat:core:tasks:compile No compilation jobs to compile +1ms
  hardhat:core:hre Running task compile:solidity:log:nothing-to-compile +1ms
  hardhat:core:hre Running task typechain:generate-types +0ms
No need to generate any newer typings.
  hardhat:core:hre Running task compile:solidity:log:compilation-result +2ms
  hardhat:core:hre Running task compile:remove-obsolete-artifacts +0ms
  hardhat:core:hre Running task test:get-test-files +80ms
  hardhat:core:hre Running task test:setup-test-environment +8ms
  hardhat:core:hre Running task test:show-fork-recommendations +1ms
  hardhat:core:hre Running task test:run-mocha-tests +0ms
  hardhat:core:hre Running test:run-mocha-tests's super +0ms
  hardhat:core:hre Creating provider for network hardhat +1s
An unexpected error occurred.

Runtime error: expected the system to be little-endian!
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I searched through this entire repo, but did not see any mention of this error message.
Also, I did strace yarn test hoping it would give some hints, but then again no luck.

Would you please help point me to where in the code this error is generated from ?. Also, would you be interested to add support for big endian architecture ?

Also, how do we debug any failures ?

Thank you very much,

• Vishwanath -

This conditional in the _getOrderStatusAndVerify function could be simplified to reduce redundancy, gas cost, and increase readability. Improvement proposal:

if (numerator != 0) {
    // The order must not be partially filled when not allowed.
    if (onlyAllowUnused) {
        revert OrderNotUnused(orderHash);
    // The order must not be entirely filled.
    } else if (numerator >= denominator) {
        revert OrderUsed(orderHash);
    } 
}

This change reduces the number of comparisons from at most 3 to 2 and, hence, saves gas.

On a side note: Consider renaming the errors OrderUsed to OrderAlreadyFilled and OrderNotUnused to OrderPartiallyFilled to differentiate the similar-sounding errors.

https://discord.gg/4kJwe9R3Kk

This was previously reported through slack.

To favor explicitness and readability, several parts of the contracts may benefit from better naming. These are some examples in which naming can potentially make the code harder to read and reason about:

• There is a _fulfillOrder function and a _fulfillOrders function, but their implementations and functionality are quite different.
• There are an Order, an AdvancedOrder and a BasicOrderParameters structs, among other order related structs. However, the names of functions that receive these structs as parameters don't always reflect the type of the order. Two examples are:
  • _validateOrderAndUpdateStatus receives an AdvancedOrder
  • _fulfillOrder receives an AdvancedOrder
• Several functions perform too many unrelated operations within them, and their names don't always reflect their functionality. Some examples are:
  • _performTransfers also handles applying the specified fraction
  • _validateOrdersAndApplyPartials also adjusts the price, applies criteria resolvers and updates the order's status

There are multiple other examples of this, and combined with a large call depth (functions that call functions that call other functions), building a mental model of what the code is doing becomes particularly hard, as an external reader has to pretty much memorize exactly what each of these functions and their variations do, because it is not easy to determine by looking at their names.

Consider using more descriptive names for variables, functions and structs, and potentially refactoring large functions into simpler ones that perform specific and self-contained tasks.

Hi guys, so I am trying to implement seaport with my own stack.

Was trying to write some docs and stumbled upon zone and zoneHash, so I wanted to clarify my understanding about it.

1. Zone is a contract address of the onchain validator, this validator will check order data and also zoneHash validity, we have to write our own validator that implement the already declared interface
2. Zone Hash is 32 Bytes long string generated by server to make sure that only the desired zone is able to validate this order

CMIIW, thanks

Q: isnt the main "create an NFT with opensea" contract an 1155? lets check how much volume that is getting vs 721 tokens.

by default, are we going to be using fulfillOrder function more, or these basicFullfill functions?

multiple implementations of multiple batches of 1155 hh tests

Throughout the codebase, typographical errors were found. In particular:

• Duplicated "all" word in line 13 from ConsiderationBase.sol.
• "along with as set of" should be "along with a set of" in line 542 from Consideration.sol.
• "Verifiy" should be "Verify" in line 164 from ConsiderationPure.sol.
• "offerComponents" should be "considerationComponents" in line 593 from ConsiderationPure.sol.

To improve the overall consistency and readability of the codebase, consider correcting this and any other typographical errors throughout the codebase.

Prepare a PR for converting the six "basic" order fulfillment endpoints into a single endpoint, then (assuming gas is ok) add back as many delegated functions as we can into the core contract

fulfillBasicEthForERC721Order,
fulfillBasicEthForERC1155Order,
fulfillBasicERC20ForERC721Order,
fulfillBasicERC20ForERC1155Order,
fulfillBasicERC721ForERC20Order,
fulfillBasicERC1155ForERC20Order