Masternodes

Dash Intents is an open protocol with an open role. The software is MIT licensed and anyone may run it, read it, modify it, or redistribute it — and anyone may run a market maker.Masternode operators are the verified tierof that role: a trust signal, not an access gate.

Running the software needs no permission. Presenting a ProTxHash that the chain confirms is what marks your offers as verified.evomm profile prints exactly which of those two states you are in. Those positions are not in tension: the software is free, the role is open, and verification is proven.

Verification source

The resolver is a current masternode check against Dash Core RPC:

protx list valid

The SDK's verifyMasternode makes exactly that call and matches on the ProTxHash.

Platform's own API exposes no masternode list:currentQuorumsInfo() returns quorum hashes, types, member counts, thresholds, and verification flags — never member identities. A quorum states that a validator set exists and how large it is; it never states who is in it. Epoch data is also far too slow for a live check, since an epoch is measured in days.

Three checkpoints that protect the protocol

Protection against bad actors comes from three distinct places, none of which is the relay.

  1. Verified counterparties are active masternodes. A verified offer carries a ProTxHash. It is resolved against protx list valid. Unverified offers are permitted but labeled as unverified, and a client can filter them out, whichever relay carried them.
  2. Payment to a verified market maker goes only to a chain-derived address. A verified counterparty never supplies a receiving address. The address is read from Dash Core's own record for the verified ProTxHash, so there is no field in which a verified counterparty could redirect a payment.
  3. Sanctions screening is a stated commit- ment. The protocol will screen counterparties against the OFAC SDN list before a settlement is broadcast. This is acommitment, not a claim: it is not implemented yet, and it is listed as unfinished work. SeeCompliance.

Why the relay is not a checkpoint

We are not implementing domain-based or IP-based filtering. A relay does not enforce who may publish and is trivially replaced. Our client software views every offer it can see, and labels every offer by whether it verifies against a current masternode. Verification lives in the client's verification step; the relay is transport.

Running a market maker

evomm profile      # who am I, and may I participate?
evomm --check      # validate config and keys before touching a relay
evomm tui          # live dashboard
evomm web          # loopback web UI
evomm run          # the daemon, as systemd starts it

evomm run exits non-zero while the network loop is unimplemented, rather than pretending to be running. The daemon is headless: systemd runs it without a terminal, so the dashboard is opt-in. The web UI binds to loopback only, and there is deliberately no flag to widen the bind.

The signing key is read only from the environment or from a mode-600 file, and is never passed as a flag.

Current status

The daemon is not ready for mainnet. Configuration, key custody, all three interfaces, quoting, inventory and risk limits, fee calculation, and Nostr event construction with Schnorr signing are working and tested. The relay publish and subscribe loop isnot implemented. Platform document writes are not implemented.