mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-09-20 06:45:49 -04:00
93 lines
4.1 KiB
Markdown
93 lines
4.1 KiB
Markdown
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.
|