Opensea Signed NFT Orders and Seaport Settlement
Opensea uses Seaport to settle signed NFT orders on Ethereum Virtual Machine (EVM) networks through on-chain NFT and payment transfers. A listing or bid records its maker's terms without moving the NFT at signing. Fulfillment checks the order's authorization and live conditions within the transaction that executes its transfers. A signature authorizes those terms; successful settlement changes ownership and distributes payment.
The order's maker supplies its offered assets, while the fulfiller supplies or arranges the required consideration. Those roles reverse between a sale listing and a purchase offer. Token approvals and order cancellation affect whether either path remains executable.
Buying a listing or accepting a bid
The NFT seller signs a sale listing, while a bidder signs a purchase offer; the signer becomes the offerer in either order. In a sale listing, the offer contains the NFT and the consideration specifies payment recipients. In a purchase offer, the bidder supplies the offered payment token and requires the NFT as consideration. The holder accepting that bid supplies the NFT. Seaport also supports multiple items on either side of an order, allowing more complex exchanges at protocol level.
An NFT's contract address and token identifier distinguish its on-chain identity within the order.
What must be authorized before a Seaport order can fill?
Seaport needs valid order authorization and sufficient token transfer permissions for every account supplying assets through the selected fulfillment path. Signing a Seaport order does not create the token approvals needed to transfer its assets.
Order authorization
Standard Seaport order signatures use EIP-712 typed data to bind the terms to a chain ID, protocol version and verifying contract. The maker can also register authorization on-chain through validate. In Seaport 1.6, the designated zone must authorize restricted orders when another account calls fulfillment, including the offerer. Neither signing nor validation establishes that the assets remain available, so the supplying accounts must have sufficient balances when transfers execute.
Transfer permissions
Token approval authorizes a spender or operator to move assets. Transfers can use approvals granted directly to Seaport or to a conduit, a separate transfer contract. The maker's order selects their path; standard fulfillment separately specifies the fulfiller's path.
NFT operators
An ERC-721 approval can cover a specific NFT or an operator's access to the owner's NFTs in that token contract. Collection-wide permission can therefore extend beyond the item named in a listing. The required operator must match the transfer path: approving a conduit does not grant the same permission to Seaport directly.
Payment allowances
ERC-20 payments require enough token balance and allowance for the actual spender. Native-currency payments travel with the fulfillment transaction and do not use ERC-20 allowances. Gas uses the network's native currency. Signing has no gas charge, although establishing a missing approval requires an on-chain transaction. Inspecting the signed items matters even when the wallet displays no transaction fee.
How can you confirm a Seaport order actually settled?
A Seaport fill needs a successful on-chain transaction receipt with the relevant fulfillment event and NFT transfer records to establish completed settlement. The marketplace's fulfillment response prepares transaction data; it does not execute transfers. An order hash identifies signed terms, and a submitted transaction hash identifies a transaction. Neither establishes a completed sale. The receipt's OrderFulfilled event associates the fill with its order and transferred items. NFT transfer records identify the item and receiving address. If fulfillment reverts, its transfers and event logs do not persist.
Order status also records the filled fraction. A validated flag records authorization, so it cannot establish that the entire order has filled.
Fixed amounts and time-dependent order terms
A fixed-amount order gives each item equal startAmount and endAmount values, keeping its signed amount unchanged throughout the order's active window. Different endpoint amounts create a time-dependent price or quantity.
Seaport derives changing item amounts by linear interpolation between their signed start and end amounts.
The block timestamp at execution determines the calculation. The contract also applies rounding rules, so token base units matter when translating displayed amounts into transaction values.
Marketplace fees and any included creator royalties can have separate consideration recipients. The buyer's payment covers the required payment entries; seller proceeds represent only the seller's allocation. Gas adds a separate execution cost.
A changing amount can differ from an earlier quote when transaction inclusion takes longer. Protocol-level matching can enforce explicit spending or receipt limits through an additional order. A marketplace interface need not expose every matching feature.
A fixed-price order under a payment ceiling
In this hypothetical case, a buyer sets a payment ceiling of 0.855 units of the listing's token, excluding gas. Assume an active, fully fillable NFT listing and a conventional token with sufficient decimal precision and no transfer deduction. All required authorizations and balances are available.
The fixed-price order allocates 0.835 units to the seller and 0.015 units to another consideration recipient. Its required payment totals 0.850 units, below the ceiling. A time-varying alternative meets the same constraint only when its execution-time total also fits. The buyer selects the fixed-price order for its unchanged signed amounts.
Successful fulfillment transfers the listed NFT to the buyer and distributes the specified payments. The buyer spends 0.850 token units, leaving 0.005 units below the payment ceiling. The receipt identifies the filled order and NFT recipient; gas remains a separate native-currency expense.
A competing fill, expiry or revoked approval defeats the assumed availability before execution. A reverted fulfillment does not deliver the NFT.
Expiry, cancellation and restored approvals
A signed order stops satisfying its time condition when the blockchain timestamp reaches endTime, even if a marketplace still displays it. Seaport also permits an individual on-chain cancellation by the offerer or the order's zone. The cancellation takes effect when its transaction executes successfully.
Changing an offerer's Seaport counter invalidates orders signed with the earlier counter on that deployment.
This broader action affects other orders sharing the old counter, so it has wider consequences than cancelling one listing.
Orders protected by SignedZone can qualify for gas-free, off-chain cancellation through Opensea. That cancellation stops new fulfillment signatures. Previously issued signatures remain usable until their recorded expiry, subject to the order's other conditions. The cancellation response reports the last issued signature's expiry. A recently created listing may require the on-chain route if Opensea's off-chain cancellation endpoint rejects it. Revoking a token approval blocks the affected transfer while that permission is absent. It does not cancel the signed order. Restoring approval can restore fillability if the remaining conditions still hold.
An uncancelled, inactive listing can become fillable again if its NFT returns before expiry and the maker still grants the necessary transfer permission.
Can Seaport fill only part of an NFT order?
Seaport supports partial fills only when the order permits them and every offered and consideration amount scales cleanly into integer token units. ERC-1155 orders can cover multiple copies, making divisibility relevant to both NFT quantity and payments. An individual ERC-721 token cannot split into fractional ownership through this mechanism. Advanced fulfillment supports permitted partial quantities and criteria resolution. Basic fulfillment requires a suitable fixed-amount order and the full amount to remain fillable. These are protocol capabilities; the marketplace determines which operations its interface offers.
An advanced fill may shrink to the remaining unfilled portion if another transaction fills part of the order first. An exact-quantity requirement therefore needs an appropriate full-fill or explicitly constrained matching path. Partial orders suit incremental sales; full-fill terms bind the sale to its entire signed quantity.
Details worth knowing about Opensea
Can a smart-contract wallet authorize a Seaport order?
Seaport can validate smart-contract wallet signatures through EIP-1271. The wallet's isValidSignature logic determines whether the supplied order signature passes. Once an order has already been validated or partially filled, Seaport can skip that signature check. Changing wallet signing rules alone therefore may not invalidate a previously authorized order.
How do collection criteria identify the NFT a Seaport order accepts?
Criteria-based Seaport orders can encode a permitted set of NFT identifiers as a Merkle root. Fulfillment supplies an identifier and, for a nonzero root, an inclusion proof. A zero root accepts any transferable identifier from the specified token contract. Additional marketplace or zone restrictions can still narrow eligibility, including trait rules checked when fulfillment data is prepared.
Is a batch of Seaport orders always all-or-nothing?
Seaport's fulfillAvailableOrders and fulfillAvailableAdvancedOrders methods can skip inactive, cancelled or already fully filled orders. Missing approval, insufficient balance or a failed transfer can cause the entire batch to revert.
Does signing several Seaport orders together require them to sell together?
Bulk signing creates independently fillable orders. Each order retains its own asset terms and fulfillment status. A bundle placed inside one order has a different structure: its offered items belong to the same order and follow that order's full-fill or partial-fill conditions.
What happens when an ERC-1155 recipient cannot accept the transfer?
A contract receiving an ERC-1155 transfer through Seaport must accept the receiver callback. The single-item transfer path calls onERC1155Received and checks its acceptance value. A missing function or rejected callback makes the transfer fail and causes fulfillment to revert. This requirement concerns contract recipients; an ordinary externally owned address does not need receiver code.
Can the NFT recipient differ from the wallet submitting fulfillment?
Seaport's advanced fulfillment method can direct offered items to a recipient different from the transaction caller. For a listing offering an NFT, this permits a separate receiving address. It does not replace recipients already encoded in signed consideration items. The marketplace interface must expose compatible recipient controls for that choice to be available there.