A pre-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 solvers to deliver it.
Requested
600 DASH
Structure
6 × 100
Framing
1 retro · 5 prospective
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 solvers compete to satisfy it. The best offer wins and the trade settles. The user never picks a route, because routing is the solver's problem — competition on price replaces route selection.
Why this is your proposal
The solvers are Dash masternode operators. That is the whole strategic argument:
No new hardware
You already run infrastructure. A solver adds no server.
No new capital
You already hold Dash. A solver requires no new position.
Your stake is the credential
Participation is restricted to verified masternodes — collateral already at stake, no anonymous capital.
What a solver earns
Two ways. First, the spread between the input you accept and the output you deliver — you set the ceiling yourself. Second, the protocol fee, charged in basis points on executed volume and accruing 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.
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
- Protocol API (/v1) on Cloudflare Workers
- SDK for TypeScript and JavaScript
- Masternode daemon in Rust, with a text menu and terminal dashboard
- Nostr offer layer
- Website and documentation
- NIP-05 identity published
The design is deliberate about where data lives. Three documents define the protocol — intent,offer, andsettlement. The Dash Platform contract is written exactly twice per intent, once at creation and once after settlement. Offers are exchanged over Nostr instead, 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.
Writes return 501
The API reads from the contract but does not write yet. Write endpoints return 501 rather than reporting a success that never happened.
Testnet only
The mainnet contract is not registered. That needs a funded mainnet identity — a discrete step, but not done.
Write-path trust model undecided
A Cloudflare V8 isolate cannot perform the required signature operations. Writes must be signed client-side or by a signing service holding keys off the isolate. Both work; neither is chosen. This is the largest remaining item.
Solver publishing is blocked
The relay's NIP-05 whitelist is domain-based and, as configured, excludes every independent solver — including our own domain. A third-party configuration, and the critical path.
Read endpoints return 523
The DAPI host the Worker reads through is unreachable, so endpoints that need an on-chain read fail at the upstream. The Worker itself is up. An infrastructure outage, not a code defect.
No CI is running
The workflows are registered but no job has ever executed; every run fails at startup in under a second. Everything was built and shipped by hand.
What the 600 DASH pays for
6 monthly cycles of 100 DASH. That is one engineer, part-time. There is no second line item — no infrastructure budget, no contingency, no subcontracted work.
| Cycle | Deliverable | Amount |
|---|---|---|
| 1Retro | Already published — protocol built and deployed on testnet | 100 DASH |
| 2Prospective | Write path shipped; relay whitelist resolved | 100 DASH |
| 3Prospective | Solver packaging and key custody | 100 DASH |
| 4Prospective | Pricing configuration and operations runbook | 100 DASH |
| 5Prospective | Developer onboarding; third-party integration support | 100 DASH |
| 6Prospective | Hardening, monitoring, and handover documentation | 100 DASH |
| Total | 600 DASH | |
Cycle 1 is retroactive. Cycles 2–6 are prospective.
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 solver?
The protocol is only as good as its solver 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