Eventos de órdenes peer-to-peer

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:

• Mostro
• @lnp2pBot
• Robosats
• Peach Bitcoin

References

• Mostro protocol specification
• Messages specification for peer 2 peer NIP proposal
• n3xB