Offer lifecycle

Offers are simpler than exchanges. They have effectively four reachable states:

What each state means

• ACTIVE — buyers can still commit. The default.
• VOIDED — seller has retracted the offer. No new commits accepted. Existing exchanges continue independently.
• EXPIRED — validUntilDate has passed.
• SOLD_OUT — quantityAvailable has decremented to zero through commits.

These states are derived, not stored. The subgraph and SDK compute them from voided (bool on-chain), validUntilDate, and quantityAvailable.

Voiding non-listed offers

For non-listed (private / EIP-712) offers — those that exist as a signed FullOffer but haven't been written on-chain — voiding goes through void_non_listed_offer (or _batch) on the MCP, or the equivalent SDK method. The on-chain side records the offer hash as voided so it can't subsequently be committed to.

Common footguns

• Voiding does not refund seller deposit. Deposits are per-exchange, not per-offer; nothing is locked at creation. Any deposited, but not yet encumbered funds can be freely witdrawn.
• An offer can EXPIRE while exchanges from it are still live. The two state machines are independent.
• SOLD_OUT is observed, not declared. If you need precise inventory, read quantityAvailable from the contract, not the subgraph, to avoid lag.

Next

• Build → Sellers → Publish an offer.
• Build → Marketplace operators → Search & discovery for filtering by state.