← All NIPs

NIP-69

Peer-to-peer Order events

DraftEvents

A shared format for bitcoin buy and sell offers, so P2P trading platforms can publish into one public order book instead of separate silos.

At a glance

Status
In use and still allowed to change.
Kinds
Tags
  • amt
  • bond
  • d
  • expiration
  • expires_at
  • f
  • fa
  • g
  • k
  • layer
  • name
  • network
  • pm
  • premium
  • rating
  • s
  • source
  • y
  • z
Last changed
Nov 13, 2025

Try it

Edit the form or the JSON: both stay in sync, the badge says whether the result is valid, and tapping any field explains it.

Examples
Valid 1 note

Not signed yet · Demo keys only. These personas' secret keys are public on purpose.

Form
Jan 1, 2025, 12:00 AM UTC

Content

This kind has no content: leave it as an empty string.

Tags

  1. d Required

    Order id, unique per maker.

  2. k Required

    Order type.

  3. f Required

    Fiat currency.

  4. s Required

    Order status.

  5. amt Required

    Bitcoin amount.

  6. fa Required

    Fiat amount: a fixed amount, or min and max for a range order.

  7. pm Required

    Accepted payment methods.

  8. premium Required

    Premium over market price.

  9. rating Optional

    The maker's reputation on the platform.

  10. network Required

    Bitcoin network.

  11. layer Required

    Where the bitcoin moves.

  12. name Optional

    Maker's display name.

  13. bond Optional

    Security deposit both sides pay.

  14. expires_at Required

    When a pending order should turn expired.

    Jan 2, 2025, 12:00 AM UTC
  15. expiration Required

    When relays may delete the event (NIP-40).

    Jan 9, 2025, 12:00 AM UTC
  16. y Required

    Platform that created the order.

  17. z Required

    Document type.

Add tag

How this NIP works

Step 1 of 5

One order book for everyone

Each platform publishes its offers as addressable kind 38383 events. Any client can show offers from all platforms together, which means more liquidity for traders.

In the course

No course chapter covers this NIP yet. The editor above is the quickest way in.

Builds on

See also

Specification

Specification text is quoted in English from the nostr-protocol/nips repository. Our explanations and the interface are translated. Source on GitHub at commit 0046368

Read the spec572 words, quoted from the repository at commit 0046368.

Abstract

Peer-to-peer (P2P) platforms have seen an upturn in recent years, while having more and more options is positive, in the specific case of p2p, having several options contributes to the liquidity split, meaning sometimes there's not enough assets available for trading. If we combine all these individual solutions into one big pool of orders, it will make them much more competitive compared to centralized systems, where a single authority controls the liquidity.

This NIP defines a simple standard for peer-to-peer order events, which enables the creation of a big liquidity pool for all p2p platforms participating.

The event

Events are addressable events and use 38383 as event kind, a p2p event look like this:

{
  "id": "84fad0d29cb3529d789faeff2033e88fe157a48e071c6a5d1619928289420e31",
  "pubkey": "dbe0b1be7aafd3cfba92d7463edbd4e33b2969f61bd554d37ac56f032e13355a",
  "created_at": 1702548701,
  "kind": 38383,
  "tags": [
    ["d", "ede61c96-4c13-4519-bf3a-dcf7f1e9d842"],
    ["k", "sell"],
    ["f", "VES"],
    ["s", "pending"],
    ["amt", "0"],
    ["fa", "100"],
    ["pm", "face to face", "bank transfer"],
    ["premium", "1"],
    [
      "rating",
      "{\"total_reviews\":1,\"total_rating\":3.0,\"last_rating\":3,\"max_rate\":5,\"min_rate\":1}"
    ],
    ["source", "https://t.me/p2plightning/xxxxxxx"],
    ["network", "mainnet"],
    ["layer", "lightning"],
    ["name", "Nakamoto"],
    ["g", "<geohash>"],
    ["bond", "0"],
    ["expires_at", "1719391096"],
    ["expiration", "1719995896"],
    ["y", "lnp2pbot"],
    ["z", "order"]
  ],
  "content": "",
  "sig": "7e8fe1eb644f33ff51d8805c02a0e1a6d034e6234eac50ef7a7e0dac68a0414f7910366204fa8217086f90eddaa37ded71e61f736d1838e37c0b73f6a16c4af2"
}

Tags

  • d < Order ID >: A unique identifier for the order.
  • k < Order type >: sell or buy.
  • f < Currency >: The asset being traded, using the ISO 4217 standard.
  • s < Status >: pending, canceled, in-progress, success, expired.
  • amt < Amount >: The amount of Bitcoin to be traded, the amount is defined in satoshis, if 0 means that the amount of satoshis will be obtained from a public API after the taker accepts the order.
  • fa < Fiat amount >: The fiat amount being traded, for range orders two values are expected, the minimum and maximum amount.
  • pm < Payment method >: The payment method used for the trade, if the order has multiple payment methods, they should be separated by a comma.
  • premium < Premium >: The percentage of the premium the maker is willing to pay.
  • source [Source]: The source of the order, it can be a URL that redirects to the order.
  • rating [Rating]: The rating of the maker, this document does not define how the rating is calculated, it's up to the platform to define it.
  • network < Network >: The network used for the trade, it can be mainnet, testnet, signet, etc.
  • layer < Layer >: The layer used for the trade, it can be onchain, lightning, liquid, etc.
  • name [Name]: The name of the maker.
  • g [Geohash]: The geohash of the operation, it can be useful in a face to face trade.
  • bond [Bond]: The bond amount, the bond is a security deposit that both parties must pay.
  • expires_at < Expires At>: The expiration date of the event being published in pending status, after this time the event status SHOULD be changed to expired.
  • expiration < Expiration>: The expiration date of the event, after this time the relay SHOULD delete it (NIP-40).
  • y < Platform >: The platform that created the order.
  • z < Document >: order.

Mandatory tags are enclosed with <tag>, optional tags are enclosed with [tag].

Implementations

Currently implemented on the following platforms:

References