Today, we’re excited to announce Seaport, a brand new web3 marketplace protocol for safely and efficiently buying and selling NFTs. We’re incredibly excited to be building on top of it, and while we’ve created the first iteration of Seaport, this protocol is not just for OpenSea – but for all builders, creators and collectors of NFTs. The core smart contract is open source and inherently decentralized, with no contract owner, upgradeability, or other special privileges.

Seaport Deep-Dive

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.

Open Source

This is only the beginning for Seaport. We built the initial version of the protocol to unlock use cases and optimizations that creators and collectors expect from a modern web3 marketplace. However, what we’ve really built is a foundation to empower the developer community to work together on this primitive. OpenSea does not control or operate the Seaport protocol — we will be just one, among many, building on top of this shared protocol. And so, as adoption grows and developers create new evolving use-cases, we are all responsible for keeping each other safe. We urge all interested smart contract developers to take a look and help optimize, simplify, and review potential areas of security concern.

The Seaport contracts emphasize efficiency and contain a significant amount of low-level assembly code. We’ve included a reference implementation that replicates the functionality of the optimized contract without any assembly code to enhance readability. We highly recommend contrasting the two implementations to familiarize yourself with the code (or even as an educational resource!) and encourage you to review and ask questions directly on the GitHub project — ongoing community engagement and participation is critical to the ongoing security and evolution of the protocol.

On that note, we are kicking off a two-week audit contest with code4rena with a $1 Million prize pool — the largest pool size in their history — starting today!

Audits

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.

Seaport would not be what it is today without the efforts of many talented external contributors and reviewers, including Dillon Kellar, transmissions11, samczsun, Riley Holterhus, brockelmore, and fiveoutofnine.

For more technical details and to start diving deep into the protocol, visit the GitHub repository and the interface documentation page.