OpenSea has launched ‘Seaport,’ its newest NFT marketplace, providing multiple ways for listings to be fulfilled.
The marketplace will offer innovative ways for users to buy and sell NFTs, including the ability for bidders to pay for NFTs using different assets, rather than just crypto.
OpenSea says that every Seaport listing will consist of the same basic structure, including an improved EIP-712 signature payload, which outlines what can be spent and what will be received back.
Most current NFT marketplaces only allow for listings where one party agrees to supply an NFT and the other agrees to supply a payment token. Seaport takes a different approach: offerers can agree to supply a number of ETH / ERC20 / ERC721 / ERC1155 items — this is the “offer.”
In order for that offer to be accepted, a number of items must be received by the recipients indicated by the offerer — this is the “consideration.”
Every Seaport listing consists of the same basic structure, including an improved EIP-712 signature payload that clearly outlines what can be spent and what will be received back by whom. However, there are a number of different ways that the fulfiller can choose to have listings fulfilled.
The most straightforward fulfillment option involves choosing a specific listing and creating an implied “mirror” of that listing, where the fulfiller receives all offer items and supplies all consideration items. Seaport also supports the option to fulfill any number of listings at once through a set of “fulfillments” — each fulfillment corresponds to a single item transfer and indicates a group of offer items that the submitter can match with corresponding consideration items. As long as each consideration item on each listing is fully credited after all fulfillments have been applied, the offerers can leverage their coincidence of wants and complete their transfers. This enables elimination of redundant transfers (which are generally the most gas-intensive component of the protocol) and allows for novel and efficient transactions.
Offerers may also optionally elect to designate both a “zone” and a “conduit” on any listing. Anyone can create new zones or deploy new conduits. A zone is an account (usually a contract) that performs additional validation prior to fulfillment, and that can cancel the listing on behalf of the offerer.
A conduit is a contract where offerers set token approvals. The owner of the conduit can add and remove “channels” for the conduit, and registered channels can instruct the conduit on how to transfer tokens. These two concepts enable extensibility and upgradeability in a fully “opt-in” fashion, giving creators, collectors, and platforms additional ability to make their own choices regarding how they utilize Seaport while maintaining broad composability with other listings on the protocol.
Each item on a listing can also optionally specify that some “criteria” be met in place of requiring a specific tokenId, enabling collection-level and trait-level offers. Furthermore, each item can specify a distinct “start amount” and “end amount” which are then compared to the current time as well as the start and end time of the listing to derive a current amount — this enables ascending and descending amount mechanics such as reverse dutch auctions.
Additionally, any listing can also opt to support partial fills of offered items, where fulfillers can elect to spend some portion of each of the total offered items and receive back an equivalent portion of each consideration item as long as the relative ratios remain unchanged based on the initial offer. Offerers can combine partial fills with criteria-based items to create standing offers to buy or sell multiple NFTs that all share a given characteristic.
Finally, the Seaport protocol supports “tipping” — a fulfiller may include additional consideration items when fulfilling a listing as long as they do not “tip” more than the original offer. This allows alternative interfaces to include their own fees, and can be combined with zones to support listings with dynamic amounts and recipients, as well as other novel applications like on-chain english auctions.
“As adoption grows and developers create new evolving use-cases, we are all responsible for keeping each other safe,” OpenSea said, clarifying that it would not be the one controlling Seaport, but rather an independent open-source protocol for several developers to build upon.
OpenZeppelin performed a security review of the Seaport protocol early in the development process, and Trail of Bits conducted an audit of the protocol near the completion of the current deployment. No major vulnerabilities were discovered as part of either review. The full report from Trail of Bits is available here.
For more technical details and to start diving deep into the protocol, visit the GitHub repository and the interface documentation page.
