Commerce Standards
Read the commerce NIPs by product consequence, not by number. NIP-99, NIP-69, NIP-75, NIP-90, NIP-47, NIP-57 and the older NIP-15 each answer a different market question.
The map starts with use cases
A standards page becomes useful only when it starts with the product consequence. You do not arrive at Commerce wanting a random NIP number. They arrive with a question: how do I list a product, publish an order, fund a project, request compute, connect a wallet, record a zap or understand an old marketplace implementation?
That is why this page is organized by commercial job. NIP-99 is for classified listings. NIP-69 is for peer-to-peer orders. NIP-75 is for zap goals. NIP-90 is for data vending jobs. NIP-47 is for wallet connections. NIP-57 is for Lightning zaps. NIP-15 is the older full marketplace attempt now marked unrecommended.
This framing keeps you out of protocol fog. A standard matters only when it changes what a builder can ship or what a user can understand.
NIP-99: listing first
NIP-99 gives the market a lightweight listing object. It defines kind 30402 for classified listings and kind 30403 for draft or inactive listings. The event can carry title, summary, published_at, location, price, status, categories and images. It can describe goods, services, work opportunities, rentals, free items and other offers.
The product consequence is simple: a client can show listings without implementing a full merchant checkout system. That makes NIP-99 attractive for Shopstr-style public offer shelves and classified experiences.
The limit is also clear. NIP-99 does not solve orders, support, inventory, escrow or buyer protection. It gives the offer a portable shape.
NIP-69: order liquidity
NIP-69 defines peer-to-peer order events and uses kind 38383. It carries tags for buy or sell orders, fiat currency, status, sat amount, fiat amount, payment methods, premium, rating, source, network, layer, geohash, bond and expiration. Its stated purpose is to reduce liquidity fragmentation across P2P platforms.
The product consequence is an open order book idea. Mostro, lnp2pBot, Robosats and Peach-related work appear in the implementation list. That does not mean all products behave the same way. It means clients and services can begin from a shared order event.
The risk is higher than in classifieds. P2P orders involve counterparties, off-chain fiat payment, possible disputes and local legal context.
NIP-75: fundraising as an event
NIP-75 defines Zap Goals using kind 9041. A goal has a description, target amount in millisats and relays where zap receipts can be found. It can include images, summaries, closing times, related links and beneficiary splits through zap tags.
The product consequence is that a fundraising target can live as a Nostr event and attach to profiles, long-form posts, live streams or event pages. That is different from a goal existing only inside one crowdfunding product.
The open question is trust. A goal event can be easy to create. Clients still need identity, context, progress display and abuse handling.
NIP-90: compute work, with a warning label
NIP-90 describes Data Vending Machines: customers publish job requests, service providers publish feedback and results, and payments can happen through invoices or zaps. It reserves ranges for job requests, results and feedback. It also contains a warning that the broad approach became unwieldy and that narrower microstandards may be better.
The product consequence is a marketplace for compute. Transcription, translation, machine-assisted tasks, indexing and other services can be modeled as event-driven work. But the warning matters. Builders need to be precise about the exact job, payment behavior, privacy and result quality.
In the Commerce hub, NIP-90 belongs with agent work and data vending, not with simple storefronts.
NIP-47 and NIP-57: payment rails
NIP-47, Nostr Wallet Connect, lets a client talk to a wallet service through encrypted relay messages. It can support paying invoices, creating invoices, looking up invoices, listing transactions and receiving wallet notifications. In commerce, it is the permission layer behind smoother wallet-connected apps.
NIP-57, Lightning Zaps, defines zap requests and zap receipts. It lets clients display Lightning payments tied to Nostr users and events. It is powerful for creator support, goal funding and social payments.
Together they explain why Nostr commerce often feels closer to the wallet than older web commerce. One standard connects apps to wallets. The other makes payments visible in the social graph. Neither replaces product trust.
NIP-15: important history, not the default starting point
NIP-15 attempted a fuller marketplace design: merchants, customers, stalls, products, orders, payment requests, order status updates, auctions, bid confirmations and marketplace UI customization. It was implemented by LNbits Nostr Market and Plebeian Market. It captures real commerce complexity.
It is also marked unrecommended in the canonical repository, with the note that it became too complicated and that NIP-99 is the better starting point. That is not a failure to hide. It is the lesson. Full commerce creates many moving parts quickly.
You can use NIP-15 to understand the old branch and the problems full marketplaces face, while using NIP-99 as the simpler modern listing baseline.
Status labels are part of the story
You should never have to discover late that a standard is marked unrecommended. NIP-15 and NIP-90 are especially important here. Both contain useful ideas. Both also carry warning labels in the canonical repository. That is not a technical footnote. It changes how a builder or user should treat them.
Unrecommended does not mean irrelevant. It means do not present the NIP as the obvious modern default. NIP-15 is useful history and a map of full marketplace complexity. NIP-90 is useful as a language for compute jobs and a warning about overly broad standards. The status tells you how much confidence to place in the pattern.
This is why Commerce Standards begins with consequences and status, not with a clean numbered list. You need a ranked mental model: active simple listing, active P2P order, active zap goal, wallet connection, social payment, older marketplace branch, experimental compute market.
That order helps prevent wrong product decisions.
The standards overlap in real products
A real commerce product rarely uses only one NIP. Shopstr lists support for NIP-99, NIP-47, NIP-57, NIP-60, NIP-85, NIP-98 and Blossom-related work. That stack tells the truth about commerce: a listing needs product data, a wallet path, payment proof, optional ecash, assertions or reputation, HTTP auth and media handling.
A creator tool may use long-form content, zaps, zap goals, wallet connections and media storage. A P2P product may use order events, Lightning, reputation, encrypted messages and relay policies. A marketplace may need application metadata and recommended handlers so clients know what can open what.
This overlap is why a standards page should be written like a map of interfaces. The user does not care that the standards are in separate files. The user cares whether the product works as one flow.
The archive keeps the NIP links open, but the hub explains the flow before sending you into raw specifications.
NIP-15 explains why commerce gets heavy
NIP-15 is easy to dismiss because it is marked unrecommended. That would be a mistake. It is one of the best documents for seeing how quickly commerce becomes complicated. Products, stalls, carts, payment requests, orders, shipping, status updates, auctions and UI customization all appear because real trade needs them.
The standard tried to model a marketplace as a full system. That ambition created weight. A small classified ad does not need all of it. A serious merchant platform may eventually need much of it. The lesson is not that full commerce is impossible. The lesson is that builders need to choose the smallest standard that fits the job.
That is why NIP-99 can be the starting point while NIP-15 remains a useful reference. One lists the offer. The other shows the merchant universe waiting behind the offer.
Good standards writing keeps that lineage visible.
The standard is not the user promise
A standard can describe an event shape, but it does not promise that a product is honest, usable, liquid, private or safe. NIP-99 does not prove a seller. NIP-69 does not guarantee a trade. NIP-75 does not prove a goal will deliver. NIP-47 does not guarantee wise permissions. NIP-57 does not prove the creator fulfilled anything. NIP-90 does not guarantee useful output.
This sounds obvious, but it is the most common mistake in protocol ecosystems. Builders point to a NIP and treat the implementation as trustworthy by association. You need the opposite habit. Open the NIP, then inspect the product, then inspect the human or company behind it.
That is the reason every Commerce page needs sources. The standard is evidence for the shape of the data. The product page is evidence for the implementation. The public account, repo, docs and community trail are evidence for the people operating it.
You deserve all three layers.
Read implementation lists carefully
Several NIPs include implementation references. Those lists are helpful, but they are not certification. A project can implement part of a NIP, implement an older version, support a narrow feature or stop maintaining the integration. You should treat implementation lists as starting points for inspection.
For NIP-69, implementations such as Mostro, lnp2pBot, Robosats and Peach-related announcers show that the order-event idea maps onto real P2P markets. For NIP-15, LNbits Nostr Market and Plebeian Market show the older marketplace branch. For NIP-99, Shopstr-style listings show the modern classified path.
The correct habit is source triangulation. Open the NIP. Open the repository. Open the live product if it exists. Check whether the product still behaves like the text claims. This habit keeps the archive from becoming stale mythology.
Standards pages should train that habit rather than pretending a NIP link is enough.
Optional standards still shape expectations
Many Nostr standards are optional. That word can mislead you. Optional does not mean irrelevant. It means clients and products choose whether to support the behavior. If enough products support it, users begin to expect it. If support is fragmented, the same event may feel useful in one client and invisible in another.
Commerce is especially sensitive to this. A listing that only one client displays is less valuable. A zap goal that one wallet understands and another ignores creates confusion. A wallet connection that behaves differently across products creates risk. A data vending job no one discovers has no market.
The Commerce page therefore has to ask about adoption, not only specification. Which clients support the NIP? Which products depend on it? Which pieces are experimental? Which status labels warn you to slow down?
That is how optional standards become useful to you.
The commerce stack crosses hub boundaries
Commerce standards do not stay inside Commerce. NIP-47 belongs to Wallets. NIP-57 touches People, Media and Creator Commerce. NIP-98 HTTP auth touches Apps and developer infrastructure. NIP-99 touches marketplaces. NIP-69 touches P2P trade and privacy. NIP-90 touches developer tools and agent work.
A good hub does not pretend these boundaries are pure. It uses them as reading paths. If the question is money permission, go to Wallets. If the question is a marketplace listing, stay in Commerce. If the question is a creator receiving zaps, move between Media and Commerce. If the question is data privacy, open Privacy.
This cross-linking is part of the quality standard. It prevents the site from becoming a set of isolated silos and lets you follow the real problem.
Nostr itself is composable. The archive has to be composable too.
The source map keeps old pages from misleading you
A route with many old research pages can accidentally mislead you if every page looks equally current. Standards change, recommendations change, projects go quiet and implementation notes age. The source map remains useful only when the hub explains which material is canonical, historical, experimental or product-specific.
For Commerce, that means old NIP-15 pages should point to the modern context. NIP-90 pages should show the warning label. NIP-99 and NIP-69 should be treated as living commerce paths. NIP-47 and NIP-57 should be connected to Wallets and Creator Commerce.
This approach preserves information without turning the site into a junk drawer. Nothing valuable is thrown away, but you is not asked to guess what still matters.
That is the cleanup principle for every hub in the remaining task list.
A NIP number is not enough for navigation
Most you do not arrive thinking in NIP numbers. They arrive thinking: I want to sell something, pay someone, fund a project, trade peer to peer, connect a wallet, support a creator or understand a marketplace. The hub should start there and then reveal the NIPs behind the behavior.
This is why the Commerce hub uses market paths first and standards as proof. A card labeled NIP-69 is useful after you knows it means P2P order events. A card labeled NIP-99 is useful after you knows it means classified listings.
Navigation should follow the user's problem, not the repository file name. The file name remains available for verification.
That rule will apply again to Privacy, Wallets, Relays and Governance.
Unrecommended standards still deserve careful writing
A lazy cleanup would delete unrecommended standards. That would be wrong. NIP-15 and NIP-90 both explain problems that real builders faced. They show where ambition outran simplicity and where broad abstractions became difficult.
The right cleanup is to keep them with context. Tell you they are not the recommended starting point. Explain what they attempted. Explain which products used or referenced them. Explain what newer or narrower path now makes more sense.
That preserves history and prevents cargo-cult implementation. You can learn from the old branch without being sent down it blindly.
This is the difference between an archive and a landfill.
What to open after this page
After the standards overview, open the NIP that matches the job, not the one with the most familiar number. Use NIP-99 for listings, NIP-69 for P2P orders, NIP-75 for zap goals, NIP-47 for wallet connections, NIP-57 for zaps, NIP-90 for data jobs and NIP-15 for the older full marketplace branch.
Then open an implementation. A standard becomes easier to understand when you see a product wrestling with it. Shopstr makes NIP-99 practical. Mostro makes NIP-69 practical. Geyser and zap goals make funding more concrete. NWC products make NIP-47 feel less abstract.
Keep the status labels visible while reading. Draft, optional and unrecommended are not bureaucratic tags. They are guidance. They tell you how carefully to treat a claim before building or buying around it.
Sources worth opening
These are the primary trails used for this article. Open them when you want the protocol text, repository context or project surface behind the explanation.
