Compliance
This page states, precisely and without overclaiming, what protects the protocol against bad actors today, what is committed but not yet built, and where each check can actually be enforced.
Our stated intent
Dash Intents intends to support sanctions screening. Counterparties will be screened against the OFAC SDN listbefore a settlement is broadcast, so that sanctioned actors cannot use the protocol to move value.
This is a commitment, not a claim.No sanctions screening is implemented in the software today. It is listed as unfinished work, on the same footing as the relay loop and the Platform write path. We are stating the intention publicly so that it can be held against us.
Where enforcement can live
This matters, because a policy that is described as stronger than it can be is worse than no policy at all.
| Check | Enforced by | State |
|---|---|---|
| Counterparty is an active masternode | Client, against protx list valid | Source agreed; daemon wiring unfinished |
| Payment address is not counterparty-supplied | By construction — no such field exists | Verified in the contract and the offer codec |
| OFAC SDN screening | Our client / prover, before broadcast | Basic name-screening utility in the SDK; enforcement (settlement-path wiring) not yet implemented — committed |
| Domain- or IP-based relay filtering | — | Deliberately not implemented; a relay is not a security boundary |
A limitation we will not paper over
Settlement happens on Dash Layer 1, and Dash Layer 1 has no address screening at consensus. There is therefore no point in the settlement path at which the network itself can refuse a payment to a sanctioned address.
The consequence is that sanctions screening is aself-imposed policy in our own client and prover, not a property of the network. It can be relied upon exactly because we control the client that broadcasts — and it should be understood as that, not as a chain-level guarantee.
Transparency
Settlements are recorded on Dash Platform with the transaction hash, and the payout address is derived from a verified ProTxHash rather than supplied by a participant. A settlement can therefore be checked against Layer 1 without trusting any party's report of it.
Governance
Protocol policy decisions are intended to follow masternodequorum consensus at a two-thirds threshold. The open questions this raises — comparative guardrail designs, the interaction with United States law given that most masternodes are located outside the United States, and the prerequisites for the settlement designs below — are tracked in the project's internal notes and are not yet settled.
The following are recorded as open, with no position taken: PTLCs versus HTLCs for privacy, DLEQ (discrete-log equivalence) support across candidate chains, and what is required before STARK-based settlement is achievable.