NIP-15: Nostr Marketplace
Commerce without a single marketplace owner
NIP-15 is one of the most ambitious early Nostr product standards. It imagines a marketplace where merchants publish stalls and products as Nostr events, clients discover them through relays, and checkout communication can move between merchant and customer without depending on one platform database.
The idea came from Diagon Alley and LNbits marketplace work: shift power from the frontend marketplace to the merchant's stall. If one indexer or frontend goes away, the merchant's signed product data can still be picked up elsewhere. That is a very Nostr-shaped commerce idea.
It is also a hard idea. Real commerce has inventory, shipping, payments, order status, customer support, disputes, images, categories, auctions, market branding and trust. NIP-15 tried to cover a lot of that. The current official warning now says it is too complicated and points to NIP-99 for simpler classified listings.
Stalls, products, checkout and auctions
The standard defines roles: merchant, customer, product, stall and marketplace. A merchant can publish a kind 30017 stall and kind 30018 products. Both are addressable events with d tags. Product content can carry name, description, images, currency, price, quantity, specs and shipping rules.
Checkout uses encrypted JSON messages over NIP-04. The customer sends a new order. The merchant sends payment options such as URL, on-chain Bitcoin address, Lightning invoice or LNURL-pay. The merchant later sends order status such as paid or shipped. That design reflects the period when NIP-04 was the standard DM path; today it is an obvious legacy seam.
Later additions expanded the model. Kind 30019 lets a market creator publish marketplace UI or merchant grouping data. Kind 30020 covers auction products, while kind 1021 bids and kind 1022 bid confirmations carry auction flow. That is powerful, but it also explains the warning: this is no longer a small interoperable primitive.
A marketplace standard that kept absorbing product reality
Semisol created the early draft in May 2022. Arc's PR #330 brought the Nostr Marketplace proposal into the NIPs in April 2023. The file then grew quickly: fixed links, shipping costs, country-to-region language, market UI metadata, unlimited quantities and auction support from Ioan Bizau's PR #859 in January 2024.
The implementation trail matters. LNbits NostrMarket and Plebeian Market were named in the source itself. Plebeian Market later wrote publicly about becoming NIP-15 compliant and contributing auctions to the standard. That is real product pressure, not abstract standards writing.
The later warning added in 2026 changed your interpretation. NIP-15 remains an important historical and implementation document, but it is no longer the clean default route for new lightweight commerce pages. NIP-99's classified listing model is easier for broad listings, services and simple offers.
The products proved the idea and the complexity
LNbits NostrMarket is the clearest early implementation reference. Its readme ties the project back to Diagon Alley and resilient marketplaces. The LNbits ecosystem also exposed Nostr Market clients and hosted examples, which helped turn the NIP from a file into something merchants could test.
Plebeian Market gave the idea a more consumer-facing face: buy and sell goods for sats, run community marketplaces, handle auctions and use Nostr for resilience. Its older public repository is archived, and the current product footprint has moved, which is also useful evidence. Marketplace products evolve faster than standards files.
A new builder reading NIP-15 today needs to separate the durable idea from the old mechanics. Durable: merchant-owned listings, portable product data, marketplace frontends that can come and go. Fragile: NIP-04 checkout, large structured payloads, auction edge cases, shipping rules and the expectation that every commerce app wants the same full model.
Commerce standards fail when the boring parts are underspecified
The biggest risk is not listing a product. It is everything after listing: payment confirmation, shipping, refunds, fraud, spam, jurisdiction, reputation, moderation, escrow and support. NIP-15 touches several of those topics but cannot make them disappear.
The second risk is interop by name only. Two clients can claim NIP-15 support while disagreeing on checkout expectations, auction validity, shipping interpretation or UI metadata. The official unrecommended label is a useful warning: study the history, but do not treat this as the easiest commerce foundation.
Read NIP-15 in the wild
NIP-15 tried to describe a resilient marketplace with stalls, products and checkout flow. It is ambitious, and the current ecosystem has treated that ambition cautiously because full commerce brings too many trust, inventory, payment and dispute problems for a single simple spec.
Read it beside NIP-99. A classified listing is easier to make portable than a whole shop. If you build commerce on Nostr, separate the listing, the seller identity, the payment path and the dispute process instead of hiding them behind a marketplace skin.
What changes when you actually use it
For you, NIP-15: Nostr Marketplace (for resilient marketplaces) is felt at the moment value moves or appears to move. The interface may show a zap, offer, wallet connection, token, invoice or result, but the source terms unrecommended, draft, merchant, product, marketplace, convenience decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-15: Nostr Marketplace (for resilient marketplaces) means separating money truth from social display. Budgets, invoices, mints, wallet services, receipts and settlement need their own status language. A delightful payment animation is harmless only after custody, limits and revocation are legible.
What the official file makes concrete
The official file is organized around Terms, Nostr Marketplace Clients, Merchant admin, Marketplace, Merchant publishing/updating products (event), Event 30017: Create or update a stall., Event 30018: Create or update a product, Checkout events. Inspect unrecommended, draft, merchant, product, marketplace, convenience, Marketplace, Merchant because these are the pieces most likely to surface as product behavior. Read it beside NIP-04, NIP-19 before treating it as isolated.
NIP-15: Nostr Marketplace (for resilient marketplaces) needs sharper warnings than a normal social feature. Custody, invoices, receipts, budgets, mints and settlement determine whether money really moved.
Where it breaks
The failure mode in NIP-15: Nostr Marketplace (for resilient marketplaces) is believing the social signal more than the payment proof. A zap can be visible while settlement is incomplete, a wallet connection can outlive trust, a mint can fail, and a listing can look professional without escrow or reputation.
Where this appears outside the markdown
In the ecosystem, NIP-15: Nostr Marketplace (for resilient marketplaces) sits near wallets, Lightning, Cashu, offers, receipts, jobs, goals or marketplaces. These features are exciting because value becomes visible inside social context, but they are also unforgiving. A page about value has to separate the social object from the financial fact before the design turns trust into decoration.
The nearby-standard trap
The nearby-standard trap in NIP-15: Nostr Marketplace (for resilient marketplaces) is calling every money-adjacent event a payment. Zaps, wallet connections, Cashu proofs, nutzaps, offers, orders, goals and data jobs each prove different things. Read NIP-04, NIP-19 before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-15: Nostr Marketplace (for resilient marketplaces) names the money state. It separates request, invoice, payment, receipt, token, mint, budget, listing, order and settlement. That is how a delightful wallet or marketplace surface stays honest.
What this page does not promise
NIP-15: Nostr Marketplace (for resilient marketplaces) does not turn a social signal into settled money by itself. A zap, wallet connection, listing, token, receipt or job request can be displayed beautifully while custody, settlement, refund, invoice expiry or mint risk remain unresolved. Read NIP-04, NIP-19 before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-15: Nostr Marketplace (for resilient marketplaces) with the money state, not the animation. Identify whether unrecommended, draft, merchant, product, marketplace, convenience represent a request, permission, invoice, token, receipt or listing. Then read the nearby standards and source links so custody, settlement, budget and proof are not collapsed into one cheerful payment label.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIPs mirror: NIP-15, LNbits NostrMarket, LNbits Nostr Market App, Plebeian Market old repository. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-15 source is the anchor for exact wording, and NIP-15 commit history shows how that wording moved over time. The strongest secondary clues here are NIPs mirror: NIP-15, LNbits NostrMarket, LNbits Nostr Market App. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-15: Nostr Marketplace (for resilient marketplaces): first the human promise, then unrecommended, draft, merchant, product, marketplace, convenience, then the implementation record, then the real-world failure case. That order keeps NIP-15 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What is being proven: a request, invoice, payment, receipt, token, listing, wallet permission, mint promise or job result?
- Who can spend, revoke, refund, censor or lose the funds if the service disappears?
- Does the product separate social visibility from financial settlement before you trust the flow?
What to verify before you rely on it
- Find
unrecommended,draft,merchant,product,marketplacein the official file and check where the UI exposes the same concept. - Read NIP-04, NIP-19 as context before treating NIP-15 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-15: Nostr Marketplace (for resilient marketplaces) in that order: Official NIP-15 source for the current wording; NIP-15 commit history for the change record; NIPs mirror: NIP-15, LNbits NostrMarket, LNbits Nostr Market App for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
