Repository navigation
RFC: non-custodial shared masternode collateral (draft DIPs for directional feedback) #186
Description
Multi-party payouts (DIP-0026) made the reward side of a shared masternode non-custodial, but the collateral still has to be a single output controlled by one party, so pooled masternodes remain custodial today. I have drafted a design for closing that gap, a covenant opcode (an output-template commitment, the CheckTemplateVerify idea from Bitcoin) plus an application that pools the collateral into one output that can only ever be refunded to its funders, with rewards split through DIP-0026.
These are early drafts, offered for directional feedback rather than as a formal submission. They have been through several rounds of independent adversarial review, which caught real issues that are now fixed and the principal-safety side has held up. There is no reference implementation yet and a few items are left open in the text.
Drafts: https://github.com/hilawe/dash-multiparty-collateral-dips
I would value guidance on two things before taking this further:
- Is a CheckTemplateVerify-style covenant opcode a sound foundation, given Dash is ECDSA-only with no SegWit, or is there a direction you would steer this toward instead?
- For the first version, is fixed-term and fixed-membership the right place to start, with dynamic membership and recursion deferred?
cc @PastaPastaPasta and @UdjinM6, I would value your directional take if either of you has a moment.
Thanks for any time you can give it.
Activity
Start here: point readers to the RFC discussion (dashpay/dips#186)
hilawe commentedon Jul 6, 2026
Assessment for issue comment - How the new #187 DIP by Dash Core compares to the #186 draft DIPs
Setting the two efforts side by side, since the new #187 DIP and the drafts I posted in #186 a week
before are aimed at the same problem and it is worth being precise about where they meet and where
they differ.
Short version is that the core design choice is the same in both but #187 makes it far more shippable
and the two bodies of work are mostly complementary rather than competing.
Where the designs agree
Both arrive at a consensus-enforced covenant rather than a wallet-side construction and for the same
reason. Dash has no SegWit and no Taproot, so a co-signer can malleate a funding transaction identifier
and invalidate any pre-signed refund chain built on it. Both efforts conclude that the only robust option
is to record each participant's contribution, refund destination and control key in consensus and enforce
the refund and reward split directly. #187 puts this in the provider transaction payload and my drafts
put it behind a script-level covenant.
The shared conclusions are worth listing, because a maintainer reaching the direction is the strongest
signal that they are forced by the problem and not by taste:
another participant's principal.
Which layer holds the covenant (the main divergence)
This is the real design fork between the two.
#187 puts the covenant in the provider transaction payload, extending the unreleased version 4 payload
from DIP-0026 and adding dissolution and update transaction types. There is no new script opcode. The
trust model is the same as DIP-0003 deterministic masternode lists, ownership lives in the payload and
spends are enforced in consensus. Because it adds no general primitive, the consensus surface is small and
reviewable and it can deploy in v24 alongside DIP-0026.
My drafts led with a general script covenant opcode (an OP_CHECKTEMPLATEVERIFY, CTV, style primitive)
justified on its own broad merits, with shared collateral as one application on top. That path is more
general and reusable for other constructions, but it is a much larger and more contested consensus change
that would not ride a near-term upgrade.
My own writeup listed the payload-layer approach as the alternative to the opcode, so this is the
alternative I had documented rather than a different universe. For the specific goal of shipping shared
masternode collateral, the payload-layer choice in #187 is the more pragmatic one. The general opcode
remains interesting for other use cases, but it is not on the critical path for this feature and #187 is
right not to wait on it.
Two places #187 is cleaner than what I had
Reading it closely, two of its choices are better than the corresponding pieces of my drafts and I want
to say so plainly:
height, so a signed dissolution never becomes invalid as the chain advances. This sidesteps a trap that
a fixed-template-hash covenant runs into, where a single committed spending template cannot be both
immediately spendable (for an early cooperative exit) and time-gated (for an end-of-term backstop),
because the committed lock time cannot be two values at once. Validating output inequalities in
consensus, as docs: add Decentralized Masternode Shares DIP #187 does, is more expressive than committing to one output hash and it removes the
problem instead of working around it.
exit, paying a redistributed penalty during an early period and paying nothing after it, with no
cooperation required. My design gated early dissolution behind an M-of-N committee of participant
representatives, which is heavier and depends on those signers being available. The docs: add Decentralized Masternode Shares DIP #187 exit story is
simpler and has a stronger liveness guarantee. The trade it accepts is that a single participant can
tear down the shared node during the early period by paying the penalty, so "no one party can destroy
the node" becomes "destroying it costs a compensating penalty" rather than being prevented outright.
That is a reasonable line to draw and docs: add Decentralized Masternode Shares DIP #187 documents it, including the warning that a zero penalty
permits cheap early griefing.
Where the two efforts differ in scope and therefore compose
#187 solves the small, fixed-membership, co-owned single node entirely on L1. Membership is immutable,
exit means dissolving the whole node and refunding everyone and the share table is public on-chain for
the life of the node. That is the right shape for a handful of co-owners.
The problem I have been most focused on is the retail-scale case. Mmany small funders, each contributing
well under a full collateral, joining and leaving over time, with per-funder accounting. That case needs
two things #187 does not attempt, by design. It needs the membership and accounting ledger to live off the
coinbase and off the masternode state and it needs the reward fan-out to exceed the on-chain payout
limit. Both point to Platform.
This is the piece #187 itself flags as missing. It states that Evolution-node shares need "a Platform-side
specification for distributing Platform credits according to the share table," and that without it the
Platform rewards would not follow the consensus split. That companion specification is exactly the L1 to
L2 bridge and credit rail I have been working out and it composes on top of #187 rather than competing
with it:
(DIP-0027).
records.
with no operator in the path.
The same mechanism has a useful side effect for regular masternodes, not just Evolution nodes.
The 2 to 8 cap is a coinbase-fan-out bound and the DIP-0026 limit of 8 binds direct on-chain reward
splitting, not the number of participants as such. Moving the owner-reward fan-out off the coinbase and
onto Platform credit transfers lets a Regular shared node carry more than 8 shares. The all-on-L1 design
in #187 is the right default for a small pool that wants no Platform dependency and the Platform rail is the
natural higher tier for larger pools, using the same specification either way.
Prior art worth putting on the record
There is one non-custodial shared-masternode product in production today, CrowdNode's trustless service,
and it is built on exactly the construction #187 argues against. Its collateral is an on-chain pay-to-script-hash
(P2SH) bare multi-signature output, a 3-of-3 in the example from their own signing walkthrough, spent by
a pre-signed, time-locked refund transaction that each participant signs offline. That is the
pre-signed-refund-under-malleability model the #187 motivation calls unsafe, running in the wild. It also
inherits the practical P2SH multi-signature ceiling of roughly 15 keys, from the 520-byte redeem-script limit
and it cannot express per-participant refund amounts cleanly. Both are limitations the consensus-covenant
approach removes. I mention it because it is concrete evidence that the fragile construction is not
hypothetical, it is what the market reached for in the absence of a protocol mechanism.
Soundness read
I went looking for a hole in #187, since that would be the most useful thing to contribute and I did not
find one. The forbidden-destination analysis that prevents a crafted script from freezing collateral or
making the coinbase unconstructable is thorough, the penalty-distribution math is carefully kept monotone
so validity cannot flip with block height and the requirement that the penalty stay below the smallest
share guarantees a dissolution can always pay its own fee. The one point I would keep flagged is the
values choice noted above, that unilateral teardown during the early period is compensated rather than
prevented, which is a legitimate design decision rather than a defect.
Bottom line
On the L1 primitive for a small co-owned node, #187 is the more shippable design and reaches the same core
conclusions my drafts did, with two pieces done more cleanly. The retail-scale and Platform-side half is
where the remaining, non-overlapping work sits and #187 names that half as a prerequisite it defers. The
two fit together.
hilawe commentedon Jul 10, 2026
Closing this RFC as resolved rather than withdrawn. The question it asked, whether non-custodial shared masternode collateral is feasible and which direction is right, has been answered about as well as an RFC can be, because a Dash Core maintainer has since proposed #187, which reaches the same consensus-covenant design for the single-node case on Layer 1 and is on track to ship. The point-by-point comparison is in the comment above. My work continues on the complementary half that #187 defers, the Platform-side reward distribution and the larger many-funder case, and I will bring that forward on #187 or a dedicated companion issue when it is ready. The draft DIPs and the full comparison remain at github.com/hilawe/dash-multiparty-collateral-dips. Thanks to everyone who took a look.