NIP-XXX
=======

`draft` `optional` `author:ariard`

Order
-----

This NIP defines a new event type to communicate trade orders between Nostr relays and clients.

A new parameterized replaceable event `order` is introduced `32500`. This event content field is a Lightning [BOLT12](https://bolt12.org/bolt12.html) string.

## Motivation

This proposal aims to enable peer-to-peer markets over the Nostr network, where clients can select
market places or trade counterparties with high-level of flexibility, efficiency and privacy.

Two types of peer-to-peer markets can be build from an order event:
- over-the-counter markets
- exchanges

Over-the-counter markets can be defined where a dealer is selling products for the account of its
clients to a set of market-makers, where they have commitments to the product. This can be a Nostr
encrypted or public group events, where the members are selected according to the dealer's policy.

Exchanges markets can be defined as a publication space where the makers orders are executed against
takers one by the intermediary of a brokering service. This service can be run on top of a Nostr
relay, where the makers and takers are Nostr clients.

The technical difference between OTC and exchanges lays in the lack of financial interest of
the intermediary in the trade order, and only charges a fee for the publication service. While this
distinction comes with trade-off in term of security model (e.g chain notarization of all the exchange
trades with [NIP03](https://github.com/nostr-protocol/nips/blob/master/03.md)), in practice the differences
are expected to be blurred and function of the goods/products quantity.

## Design 

The separation between the offer field related to the trade and the event fields related to the processing
of the event enable to introduce orders types based on Nostr tags e.g:
- buy/sell limit order where the offer is not more valid based on a market price indicated in a tag
- stop order where the offer becomes valid when a market price is reached or passed
- time-sensitive order where the offer becomes valid when a chain height is reached

Those orders types can be defined in future NIPs and enforced by the relay at order routing.

Merkle construction of the BOLT12 invoice signatures allow selective reveal of the offer fields and therefore
enable brokering service where a Nostr relay can announce an order to its clients, without revealing the issuer
pubkey or withholding some fields related to the order execution (e.g the `blinded_path`).

The dissociation of the event signature from the offer signature enable to transit the offer across "market
zones" (e.g from a exchange A to an exchange B) without breaking the validity of the offer signature itself.
The old order can be recycled as a new ones with corresponding tags to adapt to the new market zone policy.

## Specification

Order has the following format on the wire:

```json
{
  "id": 32-bytes lowercase hex-encoded sha256 of the serialized event data,
  "pubkey": 32-bytes lowercase hex-encoded public key of the event creator,
  "created_at": unix timestamp in seconds,
  "kind": 32_500,
  "tags": [
    ["d", "optional value"],
  ],
  "content": bolt12 string,
  "sig": 64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field
}
```

An `order` note creator note:
  - MUST set the `kind` field to `32_500`
  - MUST set the event `content` field to a valid BOLT12 string

An `order` receiving node:
  - MUST reject event of kind `32_500` if the content is not a valid BOLT12 string
  - MAY substitute the `pubkey` field by its own pubkey and re-sign the event

## Security

TODO: both relay/client-sides

## Backward compatibility
 
BOLT12-enabled Lightning wallets can read the content of order events and verify the authenticity of the payment or
trade information, without substantial change in the parsing or validation logic of the payment module. A Nostr client
is just responsible to transfer a bolt12 string to the payment module.

## Acknowledgements

The Lightning protocol development community for the BOLT12 payment protocol.