NIP-99: Classified Listings
A classified listing is simpler than a full marketplace
Nostr already has NIP-15 for structured marketplace software, but many real offers are lighter: a person selling a phone, a freelancer listing a service, a rental, a job post, a free giveaway, a local sale or a personal notice. NIP-99 gives those offers a flexible event shape.
Active listings use addressable kind 30402. Draft or inactive listings use kind 30403. The content is a Markdown description, and tags carry title, summary, published time, categories, images, location, price and status.
Because the event is addressable, a seller can update the listing without creating a new identity for the offer every time.
Structured enough to browse, loose enough to adapt
The required spirit of NIP-99 is pragmatic. A listing needs to have a title, summary, location and price where relevant. The price tag supports amount, currency and optional frequency, so a listing can be a one-time sale, monthly rental or yearly service.
Images are encouraged through image tags, so clients can build carousels. Hashtag-style t tags support categories. The status tag can mark a listing active or sold.
The official file also points to the Gamma Markets e-commerce extension, which standardizes more commerce-specific behavior while keeping NIP-99 lightweight.
Marketplaces kept circling back to simpler listings
Jon Staab added status support in January 2024. Later edits renamed parameterized replaceable events to addressable events, cleaned formatting and refined wording. In July 2025, Gamma Markets added an e-commerce use-case extension through PR #1784.
Community signals show why the NIP matters. A Stacker News issue asking for NIP-99 support names Shopstr, Plebeian Market and Conduit as Nostr marketplace apps using or moving around this style of listing.
NIP-99 does not replace all commerce flows. It creates the shared object that marketplace clients can index, display and route.
The client needs to show provenance before polish
A classifieds client needs to show seller pubkey, listing age, update time, price currency, location roughness, status and images. It needs to make clear whether the listing is a signed offer, a draft, a sold item or an imported record.
Because Nostr does not automatically provide escrow, dispute resolution or delivery, marketplace apps need their own transaction flows. NIP-99 gives the listing format, not the whole commerce stack.
Search and filters needs to treat price, location, tags and status as structured data, while preserving the Markdown content for the human description.
Listings can look official without being safe
A signed listing proves which key published it. It does not prove that the product exists, that the seller will ship, or that the price is fair. Marketplace clients need reputation, reporting, escrow or external trust systems depending on the use case.
Location and personal-service listings can also expose sensitive information. Clients need to avoid forcing overly precise location data.
Read NIP-99 in the wild
NIP-99 keeps commerce simple by modeling classified listings. A listing can say what is offered, by whom and with what details, without pretending to solve the whole market.
That modesty is a strength. You still need payment, identity, trust, delivery and dispute handling elsewhere. The listing is the start of commerce, not the court system.
What changes when you actually use it
For you, NIP-99: Classified Listings 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 kind 30402, kind 30403, draft, kind:30402, kind:30403, .content decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-99: Classified Listings 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 Draft / Inactive Listings, Content, Author, Metadata, Example Event. Inspect kind 30402, kind 30403, draft, kind:30402, kind:30403, .content, .pubkey, image because these are the pieces most likely to surface as product behavior. Read it beside NIP-15, NIP-23, NIP-58 before treating it as isolated.
NIP-99: Classified Listings 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-99: Classified Listings 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-99: Classified Listings 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-99: Classified Listings 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-15, NIP-23, NIP-58 before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-99: Classified Listings 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-99: Classified Listings 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-15, NIP-23, NIP-58 before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-99: Classified Listings with the money state, not the animation. Identify whether kind 30402, kind 30403, draft, kind:30402, kind:30403, .content 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: Gamma Markets market spec, Net::Nostr::ClassifiedListing, Stacker News NIP-99 issue, NIP-15 Marketplace. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-99 source is the anchor for exact wording, and NIP-99 commit history shows how that wording moved over time. The strongest secondary clues here are Gamma Markets market spec, Net::Nostr::ClassifiedListing, Stacker News NIP-99 issue. 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-99: Classified Listings: first the human promise, then kind 30402, kind 30403, draft, kind:30402, kind:30403, .content, then the implementation record, then the real-world failure case. That order keeps NIP-99 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
kind 30402,kind 30403,draft,kind:30402,kind:30403in the official file and check where the UI exposes the same concept. - Read NIP-15, NIP-23, NIP-58 as context before treating NIP-99 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-99: Classified Listings in that order: Official NIP-99 source for the current wording; NIP-99 commit history for the change record; Gamma Markets market spec, Net::Nostr::ClassifiedListing, Stacker News NIP-99 issue 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.
