Decentralised News · Research & market intelligence
An NFT bought below a collection’s displayed floor can still be worth less than its cost at the best usable bid. Official OpenSea, Seaport and NFTX documents show why order eligibility, funding, fees and the cost of waiting belong in the same decision.
What matters
- A collection offer is not unlimited buying capacity; remaining quantity and eligibility matter.
- A validated signature does not establish that an order can still be fulfilled. Funding, approvals and order state can change.
- The useful probability is a declared scenario input or a measured estimate from appropriate data. A target listing price is neither.
Scope of this investigation
This investigation compares 8 primary-source documents. It separates documented rules and features from DN calculations and hypothetical scenarios. Full source dates, definitions and limitations appear below.
Test the assumptions · Inspect the sources · Read the evidence table
The signal
OpenSea explicitly distinguishes active and unfunded collection offers. Seaport’s interface warns that validated orders can still be unfulfillable. Together, these documents establish why a displayed bid needs additional checks before it is used as cash value. [1] [4]
DN Alpha Thesis
The apparent profit in an NFT flip often comes from comparing a purchase with somebody else’s asking price. That comparison describes a mark, not a completed sale. An executable bid is closer to a cash exit, but only for an eligible token, remaining quantity and valid order at the time of fulfilment.
This review examines the documented mechanics behind that distinction. It does not claim to have collected a live order-book panel or operated an AI flipping bot. The calculator compares an assumed usable immediate bid with a two-outcome waiting scenario and reveals the sale probability needed to justify the latter. Its purpose is to expose assumptions, not supply a probability the evidence does not contain.
The floor and the bid answer different questions
A listing floor describes the lowest observed asking price in the chosen set. A bid describes a buyer’s offer under specified conditions. Neither is automatically the price at which every NFT in a collection can be sold. The first is an invitation to buy; the second still needs to be matched to a particular asset and current state.
OpenSea’s collection-offer guide says an individual collection offer can be accepted once, while users can create multiple offers through a quantity setting. It also describes trait-specific offers and a distinction between funded and unfunded offers. A visible collection-wide number therefore cannot be multiplied by an entire inventory without checking what remains executable. [1]
Suppose a collector acquires an NFT for 1 ETH because the floor appears to be 1.2 ETH. If the only eligible bid is 0.95 ETH before costs, the immediate liquidation comparison begins at 0.95, not 1.2. The higher number may become relevant if a buyer arrives later. That is a separate scenario with a time horizon and an uncertain outcome.
An AI agent may help search orders or identify relevant traits, but it cannot turn an asking price into a funded commitment. The first useful automation task is to explain why a specific order applies to the exact token and quantity being sold. A ranking based only on the distance below floor skips the cash question.
What makes a bid usable for this token?
Seaport’s protocol documentation requires appropriate balances and approvals and checks the order’s time range, cancellation state and filled amount. Its interface exposes order status, including the filled fraction. The same interface says that prior validation does not ensure fulfilment and recommends simulating the relevant call. These are documented requirements, not evidence that a particular order has passed them. [4] [5]
A practical bid record should identify the chain, NFT contract, token ID, payment token, order hash, offered amount, criteria and expiry. It should also record the observation time and remaining quantity. A trait label copied from a user interface is not the same thing as proving that the order’s criteria accept the token.
Funding and permission checks are time-sensitive. A buyer may use the same balance to support several offers; an earlier sale can consume funds or remaining order capacity. An approval can be revoked after a quotation. A simulation is useful evidence about the state tested, but subsequent changes can still alter execution.
Treat those observations as a sequence. First establish eligibility. Then establish the current economic terms and available quantity. Then check whether the proposed fulfilment can execute. Finally, reconcile the actual transfer. A successful last step is stronger evidence than a cached quote, and a failed intermediate step should remove the offer from an executable-value estimate rather than leave it in the chart.
The seller receives less than the headline sale amount
OpenSea’s current fee page describes a typical 1% NFT selling fee, set when a listing or offer is created, and says fees can change. It distinguishes platform fees from network gas and states that the seller normally pays gas when accepting an offer, whereas the buyer submits a purchase of a listed item. The exact order terms remain the relevant evidence for an actual sale. [2]
Royalties require their own check. ERC-2981 standardises how a contract reports royalty information; it does not itself force every transfer to pay it. OpenSea separately documents optional and enforced creator earnings for different collection arrangements. It is therefore wrong either to assume that every NFT sale has zero royalties or to apply one advertised percentage universally. [3] [6]
Build a cash waterfall from the sale amount to the seller’s receipt. Identify the platform allocation, creator payment, seller-paid gas, approvals and any additional route charges. Then check which of those amounts is already included in the quoted proceeds. Subtracting a fee twice is as misleading as ignoring it.
The same discipline applies to acquisition. Keep the purchase consideration and its additional costs together. A profitable ETH-denominated resale can still have a different outcome in a household’s reporting currency if ETH moved between purchase and sale. The tool below stays in one chosen unit and deliberately does not infer a sterling or dollar return from an ETH result.
A pool exit is an alternative, not a guaranteed floor
NFTX’s current v4 documentation describes floor tokens backed by pool NFTs, with trading through Uniswap V4 pools. Its Instant Sell page describes supported floor NFTs being exchanged for ETH or collection tokens after confirmation. That provides a different documented route from waiting for an individual marketplace buyer. It does not establish a live quote for the NFT in your wallet. [7] [8]
The receipt asset matters. Receiving a collection token preserves exposure to that collection’s token market; receiving ETH changes the exposure. A claim of instant liquidity should specify which asset the user receives and the amount after all relevant costs. A token-denominated payout is not automatically equivalent to the same marked value in cash.
The current documentation also means older tutorials need version checks. This article uses the v4 description and does not import v3 vault-fee assumptions into it. We did not inspect deployed contracts, connect a wallet or confirm that a particular collection has sufficient live pool liquidity.
An executable pool route can be a useful countercase to the claim that every NFT sale requires waiting for a named buyer. It can also be unattractive for a rare asset whose owner expects a premium. Compare the actual net pool payout with the actual eligible bid and with the clearly uncertain premium-sale scenario. A route name or a displayed floor is not enough to choose between them.
Work backwards from the probability you would need
Consider a synthetic NFT acquired for 1 ETH plus 0.02 ETH of entry cost. The assumed eligible bid is 0.95 ETH. With a 1% marketplace charge, 2.5% creator payment and 0.004 ETH of seller gas, accepting that bid leaves 0.91275 ETH. The immediate realised loss against the 1.02 ETH acquisition outlay is 0.10725 ETH. These inputs are illustrative, not a quoted collection or current order.
Now suppose the owner waits thirty days for a 1.2 ETH listing sale. The same percentage deductions leave 1.158 ETH; the example assigns no seller gas to that listing sale. If it does not sell, the assumed net recovery at the horizon is 0.67 ETH. That fallback is a separate scenario input, not today’s bid preserved for later.
A hypothetical annual holding-cost rate of 10%, applied simply to 1.02 ETH for thirty days, adds approximately 0.00838356 ETH. At a user-assumed 50% probability of the target sale, the expected scenario loss is approximately 0.11438356 ETH. The waiting scenario needs a target-sale probability of about 51.46% to exceed the immediate bid outcome and about 73.44% to recover the original acquisition outlay.
Those thresholds answer two different questions. Beating an immediate loss does not necessarily mean making a profit. At a 75% assumed target-sale probability, the model produces only about 0.00761644 ETH of expected profit. The tool has not estimated that probability. If a seller cannot support it with relevant evidence, the number remains an assumption rather than a reason to buy.
The waiting scenario has explicit limits
The model has two terminal outcomes: a target sale and a fallback net recovery. Both are evaluated at the chosen horizon, with the same incremental holding cost. It does not model the exact day of an early sale, a sequence of revised listings, multiple competing bids or a changing ETH exchange rate. This simplicity makes the assumptions inspectable, but it also limits the result.
Set the holding-cost rate to zero if no incremental financing or deliberately chosen carrying-cost allowance is being applied. The model does not also earn interest on immediate-sale proceeds. Do not add an opportunity-cost rate and then separately subtract the same foregone return. All quantities must use the same unit and horizon.
The required-probability outputs are not clamped to the zero-to-one range. A result above 100% means even a certain target sale cannot achieve the stated benchmark under the supplied costs. A negative threshold means the fallback already exceeds it. These are useful feasibility findings, not unusual probabilities.
The target net proceeds must exceed the fallback value for this particular model to make sense. If they do not, the labels no longer describe a better sale outcome and a worse fallback. The tool rejects that input combination rather than dividing by a meaningless difference. It likewise cannot verify whether the immediate bid exists, remains funded or would accept the token.
What a credible flipping record would show
A useful empirical record begins before purchases are selected. It retains eligible bids and asks, rejected orders, acquisition costs, actual receipts and unsold inventory at a declared horizon. Counting only completed profitable flips leaves out the assets for which no buyer arrived. Marking those leftovers at their owners’ asking prices does not solve the omission.
Any estimated sale probability should be specific to the decision. It needs a comparable listing price relative to usable bids, a time horizon, collection and trait conditions, and a treatment of cancellations and withdrawn listings. A market-wide turnover statistic is not automatically the chance that one particular NFT sells at a chosen premium.
For automation, separate search quality from trade economics. Finding an offer more quickly may be useful. Proving that it is eligible and reconstructing the net receipt is stronger. Showing that an agent produced better outcomes than a simple policy requires a further comparison with the same inventory, costs and observation window.
The reader’s actionable decision is whether to accept a verified net bid, wait under explicit assumptions, or avoid acquiring inventory whose exit cannot be supported. This documentary review does not select a winning NFT or bot. It supplies a more demanding definition of profit: cash or consistently valued assets actually receivable after the conditions and costs of the exit have been accounted for.
The evidence, side by side
| Source | Documented observation | Reader implication |
|---|---|---|
| OpenSea collection offers | Individual offer capacity is finite; funded and unfunded states are distinguished. [1] | Do not treat a top collection offer as unlimited cash. |
| Seaport interface | Validated orders can still be unfulfillable; status includes filled quantity. [4] | Check current state and proposed fulfilment. |
| Seaport protocol | Balances, approvals, time range and order conditions matter. [5] | Match the exact asset and remaining quantity. |
| OpenSea / ERC-2981 | Marketplace fees and royalty enforcement are separate rules. [S2–S3, S6] | Use the actual seller receipt and avoid double counting. |
| NFTX v4 | Supported floor NFTs can use a pool route; payout can be ETH or collection tokens. [7] [8] | Inspect live payout and resulting exposure; no blanket floor guarantee. |
NFT Immediate Bid versus Waiting Scenario
Synthetic two-outcome scenario. No NFT order book or trading strategy was tested.
The interactive calculator starts when this page loads. The worked examples remain available in the article.
Purchase price positive; cash inputs and days non-negative. q in [0,1]. Marketplace fee and royalty each non-negative, with combined rate below one. Target net proceeds must exceed fallback net value; immediate net cannot be negative.
No live bid validation or sale-probability estimation. Required probability above 100% indicates infeasibility; below 0% means fallback already clears the benchmark. No early-sale timing, price distribution, tax or reporting-currency conversion is modelled.
How the calculation works
acquisition: purchase_price + entry_cost
immediate_net: bid × (1 − market_fee − royalty) − bid_gas
target_net: target_price × (1 − market_fee − royalty) − listing_cost
carry: acquisition × annual_carry × days / 365
expected_profit: q × target_net + (1 − q) × fallback_net − carry − acquisition
q_to_profit: (acquisition + carry − fallback_net) / (target_net − fallback_net)
q_to_beat_bid: (immediate_net + carry − fallback_net) / (target_net − fallback_net)
Scenarios to watch
Illustrative immediate sale
A 0.95 ETH bid leaves 0.91275 ETH after the specified deductions, a 0.10725 ETH loss against 1.02 ETH acquisition cost.
Illustrative 50% target-sale probability
The thirty-day waiting scenario produces expected profit of −0.11438356 ETH. Break-even against acquisition requires about 73.44%, while beating the immediate bid requires about 51.46%.
Illustrative 75% target-sale probability
Changing only the user-assumed target-sale probability to 75% produces approximately 0.00761644 ETH expected profit. The article supplies no evidence that 75% is likely.
Method and limitations
Read eight primary documents from OpenSea/Seaport, the ERC standards repository and current NFTX v4 documentation on 14 November 2026. This is a documented mechanism comparison, not a survey of live orders.
No wallet was connected, NFT bought or sold, contract deployment audited, or historical sale-probability panel collected. Older NFTX v3 material was not used to establish current fee rules.
The calculator is a two-outcome synthetic scenario. It separates the probability needed to beat an immediate exit from the probability needed to recover acquisition cost.
An eligible bid can become unfunded, cancelled, expired or filled before execution. Neither a displayed offer nor a prior simulation guarantees the subsequent transfer.
The OpenSea fee page provides a current typical charge and a relative update label, not an exact publication date; individual order terms can differ.
Target-sale and fallback assumptions are not forecasts. A pool payout in collection tokens retains exposure that an ETH cash comparison must recognise.
Primary sources and evidence register
Source dates and reporting periods differ. Several documents from one issuer are one source family, not independent confirmations. The evidence download contains the observations used in this article.
[1] What is a collection offer? — OpenSea Help Center27 July 2026 · Help article dated 27 July 2026
- Single collection offer has one acceptance; multiple offers may be created.
- Trait eligibility and funded/unfunded offer states are distinguished.
Interpretation limit: Official documentation; documentary review only. No independent operational test was performed.
[2] What fees do I pay on OpenSea?Publication date not established; see reporting period · Relative update label only; accessed 14 November 2026
- Typical NFT selling fee 1%; set at order creation and subject to change.
- Seller submitting an offer acceptance pays gas; buyer normally submits a listing purchase.
Interpretation limit: No exact update date inferred from the relative label; individual orders may differ.
[3] How do I set creator earnings on OpenSea?20 January 2026 · Help article dated 20 January 2026
- Distinguishes optional and enforced creator earnings.
- Compatible contract arrangements can enforce sale conditions.
Interpretation limit: Official documentation; documentary review only. No independent operational test was performed.
[4] Interface — SeaportPublication date not established; see reporting period · Undated documentation accessed 14 November 2026
- Validated orders may remain unfulfillable.
- getOrderStatus exposes cancellation and filled fraction.
Interpretation limit: Official documentation; documentary review only. No independent operational test was performed.
[5] Seaport Documentation — ProjectOpenSeaPublication date not established; see reporting period · Official repository main accessed 14 November 2026
- Balances and approvals must remain sufficient.
- Fulfilment checks timing, cancellation and remaining quantity.
Interpretation limit: Official documentation; documentary review only. No independent operational test was performed.
[6] ERC-2981: NFT Royalty Standard15 September 2020 · Final standard; creation date 15 September 2020
- Standard provides royalty information and does not enforce payment on every transfer.
Interpretation limit: Foundational standard, not a current marketplace tariff.
[7] Welcome — NFTX v4 documentationPublication date not established; see reporting period · Current v4 documentation accessed 14 November 2026
- Describes floor tokens backed by pool NFTs and Uniswap V4 trading.
- Fees are described in listing/swap layers rather than deposit/redemption.
Interpretation limit: Documented design only; no deployment or live liquidity audit.
[8] Instant Sell: Turn your NFT into liquidity instantly — NFTXPublication date not established; see reporting period · Current v4 product explanation accessed 14 November 2026
- Supported floor NFTs can be exchanged for ETH or collection tokens after confirmation.
- Interface describes current payout and selling options.
Interpretation limit: Provider description; no measured fill or quoted payout is claimed.
Frequently asked questions
Is buying below the collection floor enough to show a profit?
No. A floor is an asking-price observation. Profit requires an exit or a defensible valuation after its costs and conditions; the eligible bid can be below the acquisition cost.
Does Seaport validation prove the buyer can still pay?
No. The interface says validated orders may remain unfulfillable. Current balances, approvals, quantity and conditions still matter. [4] [5]
Does ERC-2981 make royalties mandatory on every sale?
The standard supplies royalty information; it does not itself force payment on every transfer. A marketplace or compatible contract can add enforcement conditions, which must be checked separately. [S3, S6]
Where does the calculator’s sale probability come from?
From the user as an explicitly hypothetical input. The article calculates thresholds but has not estimated an empirical probability. Without suitable data, do not treat the default as a prediction.
About the Author
