A proposal to the Dash masternode network
DASH Intents
An intent-based execution layer for Dash Evolution. A user signs the outcome they want; masternode operators compete as market makers to deliver it.
Requested
600 DASH
Structure
6 × 100 DASH
6 monthly cycles
The idea
Today, moving value to or from Dash means finding a venue, choosing a route, and accepting the price that route returns. You are picking amethod when what you want is an outcome.
DASH Intents inverts that. A user signs a statement of desired outcome:
“I will pay X of A for at least Y of B, before time T.”
Independent market makers compete to satisfy it. The best offer wins and the trade settles. The user never picks a route, because routing is the market maker's problem — competition on price replaces route selection.
Why this is your proposal
The market makers are Dash masternode operators. That is the whole strategic argument:
No new hardware
You already run infrastructure. A market maker adds no server.
No new capital
You already hold Dash. A market maker requires no new position.
Your stake is the credential
Participation is restricted to verified masternodes — collateral already at stake, no anonymous capital.
What a market maker earns
Three ways, and only the first two are new. This is worth stating precisely, because a simpler version of it would be misleading.
1. As a market maker
You earn the spread between the input you accept and the output you deliver — you set the ceiling yourself. Filling intents is a service to the network, not a race against other operators; the earning is additive.
2. By participating in the Titan Pool
The Titan Pool is a shared pool of assets, managed within Evo Titan. Participants contribute assets instead of managing their own, buy shares in each pool, and receive rewards pro-rata. 20% supports the top 10 projects and teams ranked by masternode vote, divided equally among them; the remaining 80% is distributed to masternode operators.
3. From network fees
This is pre-existing — the emission and fee structure every masternode already receives. It is not a benefit of this proposal.
On top of the spread, a protocol feeis charged in basis points on executed volume and accrues to the treasury the masternode network controls.
| Trade value | Protocol fee |
|---|---|
Up to $1,000 | 15 bps (0.15%) |
$1,000 – $10,000 | 10 bps (0.10%) |
$10,000 – $100,000 | 7 bps (0.07%) |
Above $100,000 | 5 bps (0.05%) |
The tiering is deliberately regressive: small trades pay the highest rate. Small trades cost the same to settle as large ones, and raising minimums to protect margin would exclude exactly the everyday usage that makes the network useful.
Each range is inclusive at its upper bound, so a trade at exactly $1,000 pays 15 bps.
Two details are not yet determined and are not claimed here: how the 80% is distributed to masternode operators, and how masternodes receive rewards from the Treasury and from the Titan Pool. These are open design questions.
What already exists
This is not a concept. Substantially all of it is built and deployed on testnet today:
- Dash Platform Data Contract, live on testnet, v1
- SDK for TypeScript and JavaScript
- Masternode daemon evomm in Rust, with a text menu, terminal dashboard, and loopback web UI
- Nostr offer layer
- Website and documentation
- NIP-05 identity published
- Write-path prover available at prover.sansbank.dev
The design is deliberate about where data lives. Two documents define the on-chain contract — intent andsettlement. The Dash Platform contract is written exactly twice per intent, once at creation and once after settlement. Offers are never written to Platform at all; they are exchanged only over Nostr, because offer traffic is high-frequency and ephemeral while on-chain writes are rare and permanent.
What is not done
You should hear this from us rather than find it later. If any of these is a deal-breaker for you, that is worth knowing now.
The write path is not complete
Reads work against the live contract. Signature-dependent writes are served by an external prover, and prover.sansbank.dev is now available to carry them; the path is not wired end-to-end yet.
Testnet only
The mainnet Data Contract is not registered. That needs a funded mainnet identity — a discrete and well-understood step.
The write path is served externally
A Cloudflare V8 isolate cannot perform the required signature operations — ECDSA/secp256k1 throws NotSupportedError in that runtime, and Schnorr over secp256k1 is unavailable entirely. Signature-dependent work is delegated to an external prover at prover.sansbank.dev. This is the largest remaining item.
Masternode verification of offers is not yet wired
A relay does not enforce who may publish — it is trivially replaced. We are not implementing domain-based or IP-based filtering. Our client software views every offer it can see and disregards every offer not verified as coming from a current masternode. The verification source is the active masternode list from Dash Core protx list valid; what remains is to wire that check into the client.
No CI is running
The workflows are committed and registered, but no job has ever executed on this repository — every run records a startup failure and stops in under a second. Nothing is currently built or deployed by a pipeline. Everything above was built and shipped by hand.
No revenue
The protocol has not launched and has processed no volume. We are not providing a revenue forecast — any fee-revenue projection for an unlaunched protocol would be a spreadsheet, not evidence.
What the 600 DASH pays for
6 monthly cycles of 100 DASH. The work spans software engineering, infrastructure, and external resources — it is not one person's time. There is no second line item: no separate infrastructure budget and no contingency.
| Cycle | Deliverable | Amount |
|---|---|---|
| 1Retro | Already published — the Data Contract, the SDK, the daemon, the offer layer, and the sites | 100 DASH |
| 2Upcoming | Client software, "Market Maker" | 100 DASH |
| 3Upcoming | Live on Testnet | 100 DASH |
| 4Upcoming | Live on Mainnet | 100 DASH |
| 5Upcoming | Developer onboarding; third-party integration support | 100 DASH |
| 6Upcoming | Hardening, monitoring, and handover documentation | 100 DASH |
| Total | 600 DASH | |
Retro
Upcoming
Upcoming
Upcoming
Upcoming
Upcoming
Cycle 1 is retroactive. Cycles 2–6 are funded after delivery.
Cycle 1 pays for work that is already complete and published — the deliverable is the changelog above, not a promise. The five remaining cycles are funded only after their work lands.
cycle N work published → cycle N payment at the next superblock
Every disbursement is preceded by delivery, never followed by a promise. The DAO never holds funding for work that has not been done.
Why flat rather than front-loaded. The largest risk is not money — it is the relay blocker above, which is outside our control. Six equal cycles mean we are not holding five cycles of unspent funding if it turns out to be unresolvable.
What we want to know from you
We would rather ask than guess. The first question matters most.
- 1
Would you run a market maker?
The protocol is only as good as its market maker set. If the answer is no, that is the most important thing we could learn before asking the network for funding.
- 2
What would make it worth running?
What return, or what minimum volume, would justify the operational effort for you?
- 3
Is the fee structure right?
Specifically the 15 bps floor on trades under $1,000 — fair to you as an operator, or does it discourage the small-trade volume that would make the network useful?
- 4
Is anything in “what is not done” a deal-breaker?
We listed the unfinished work in detail rather than glossing it. If one of those items is disqualifying in your view, we would rather know now.
A protocol that turns your stake into a service
Dash already has a large, economically committed operator set. Intent-based execution turns that set into a market-making workforce at essentially no marginal cost to each operator.
Proposal name dash-intents · Owner sansbank ·6 × 100 DASH = 600 DASH