NIP-69: Peer-to-peer Order events
P2P markets lose power when liquidity is split
P2P Bitcoin markets are useful precisely because they avoid one central venue. The tradeoff is fragmentation. A buyer on one app cannot easily see sell orders from another app. NIP-69 tries to make orders portable enough that many P2P platforms can contribute to one larger pool.
The event is not an escrow protocol and not a dispute system. It is an order advertisement. It says what the maker wants to buy or sell, the fiat currency, amount, payment methods, premium, source, rating hints, network, layer, location and status.
That is valuable because discovery can become neutral. A relay or alert tool can watch order events across platforms and send the user to the source where the trade actually happens.
Kind 38383 as an addressable trade order
NIP-69 uses addressable kind 38383. The d tag is the order identifier. k is buy or sell. f is the fiat currency, generally ISO 4217. s is status. amt is the Bitcoin amount in sats, while fa is the fiat amount or range.
Other tags describe payment methods, premium, rating, source URL, network, layer, maker name, geohash, bond, expiration and platform identifier. The expiration and expires_at pieces matter because old orders are dangerous in trading UIs.
The standard deliberately leaves ratings and execution details to platforms. It creates shared discovery, not shared custody.
Francisco Calderon moved a P2P liquidity idea into a NIP
The visible history begins in June 2024 with Francisco Calderon's simple P2P spec proposal. Later 2024 work added source tags, optional fields and the NIP number. In 2025, Peach Bitcoin implementation context was added and order expiration support landed through PR #2118.
The external signal is also clear: P2P order alert tools and community discussions frame NIP-69 as a way to watch orders from Robosats, lnp2pbot, Mostro, Peach and future platforms without becoming the trading venue itself.
The page needs to therefore be honest: this is discovery infrastructure for P2P markets, not a complete trading protocol.
The safest implementation treats orders as claims
A client or alert service needs to show source platform, status, age, expiration, payment methods, location roughness and whether the event came from a known maker or platform bridge. It must not imply that a Nostr order is verified, funded or safe.
Mostro and lnp2pbot-style markets are the natural ecosystem. A NIP-69 watcher can aggregate and alert, while execution still happens in the original platform's flow.
A good UX lets a user filter by currency, premium, payment method, country or geohash, then opens the source order rather than pretending the Nostr event alone completes the trade.
Liquidity aggregation can aggregate scams too
A bigger order pool is useful, but fake orders, stale orders and reputation laundering become easier to spread. Clients need source reputation, expiration handling and careful language.
Geohash and payment-method data can also reveal sensitive trade behavior. P2P trade discovery needs to avoid overexposing location.
Read NIP-69 in the wild
NIP-69 models peer-to-peer order events. It is a commerce primitive for offers, purchases and trade coordination without forcing every market into one platform.
An order event is not escrow or delivery proof. You still need seller identity, payment path, terms, cancellation logic and dispute context.
What changes when you actually use it
For you, NIP-69: Peer-to-peer Order events 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 draft, d, canceled, expired, amt, fa decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-69: Peer-to-peer Order events 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 Abstract, The event, Tags, Implementations, References. Inspect draft, d, canceled, expired, amt, fa, source, mainnet because these are the pieces most likely to surface as product behavior. Read it beside NIP-40 before treating it as isolated.
NIP-69: Peer-to-peer Order events 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-69: Peer-to-peer Order events 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-69: Peer-to-peer Order events 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-69: Peer-to-peer Order events 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-40 before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-69: Peer-to-peer Order events 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-69: Peer-to-peer Order events 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-40 before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-69: Peer-to-peer Order events with the money state, not the animation. Identify whether draft, d, canceled, expired, amt, fa 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: Mostro, lnp2pBot, p2psats discussion, ISO 4217. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-69 source is the anchor for exact wording, and NIP-69 commit history shows how that wording moved over time. The strongest secondary clues here are Mostro, lnp2pBot, p2psats discussion. 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-69: Peer-to-peer Order events: first the human promise, then draft, d, canceled, expired, amt, fa, then the implementation record, then the real-world failure case. That order keeps NIP-69 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
draft,d,canceled,expired,amtin the official file and check where the UI exposes the same concept. - Read NIP-40 as context before treating NIP-69 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-69: Peer-to-peer Order events in that order: Official NIP-69 source for the current wording; NIP-69 commit history for the change record; Mostro, lnp2pBot, p2psats discussion 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.
