Architecture

Three layers, each with one job. A request is recorded, a market is made over it, and the result is recorded again.

1. Settlement layer — Dash Platform

The intent andsettlement documents live in a Data Contract on Dash Platform. Platform is the durable record: it is the part that survives a relay outage, an operator going offline, or a client being rewritten. Platform also provides the identities the protocol is built on.

2. Market layer — Nostr

Offers are not written to Platform. A quote is short-lived and competitive: publishing every competing quote on-chain would cost credits proportional to the number of market makers, and would leave dead quotes behind forever. Offers are published to a Nostr relay instead, as NIP-33 addressable events, so that a market maker republishing an offer for the same intent replaces its previous offer rather than accumulating duplicates.

3. Execution layer — the market maker

evomm is the daemon a market maker runs. It subscribes to intents, quotes them against its own inventory and risk limits, signs offers with its Nostr key, publishes them, and writes settlements.

The flow of one trade

  1. A user creates an intent. The request is written to Dash Platform as an intent document.
  2. Market makers see the intent over the relay and publish signed offers to it.
  3. The best offer wins. Selection is deterministic — seeselectBestOffer in the SDK.
  4. The fill is written to Dash Platform as asettlement document, carrying the transaction hash.

Why the relay is not a security boundary

A relay does not enforce who may publish, and it is trivially replaced by anyone who wants to run one. Treating it as an access-control point would mean the protocol's rules live somewhere they cannot be enforced. Instead, every offer is checked against the masternode list and labeled by verification tier — verified offers resolve to an active masternode — no matter which relay carried it. SeeMasternodes.