The Dash Platform Developer Documentation contains technical documentation intended to help developers quickly and easily get started with Dash Platform. The Dash Core Developer Documentation provides detailed documentation on the Dash Core code base, and serves as a reference for experienced developers. These documentation portals can help developers to quickly and efficiently integrate external applications with the Dash ecosystem. Anyone can contribute to the documentation by suggesting edits in the documentation system.
The Dash Core Team also maintains the Dash Roadmap, which sets out delivery milestones for future releases of Dash and includes specific technical details describing how the development team plans to realise each challenge. The Dash Roadmap is complemented by the Dash Improvement Proposals, which contain detailed technical explanations of proposed changes to the Dash protocol itself.
The Dash community organise discussion and development of Dash apps using the following resources:
The remaining sections available below describe practical steps to carry out common development tasks in Dash.
A multi-phased fork, colloquially known as a “spork”, is a mechanism unique to Dash used to safely deploy new features to the network through network-level variables to avoid the risk of unintended network forking during upgrades. It can also be used to disable certain features if a security vulnerability is discovered - see here for a brief introduction to sporks. This documentation describes the meaning of each spork currently existing on the network, and how to check their respective statuses.
Sporks are set using integer values. Many sporks may be set to a particular epoch datetime (number of seconds that have elapsed since January 1, 1970) to specify the time at which they will active. Enabled sporks are set to 0 (seconds until activation). This function is often used to set a spork enable date so far in the future that it is effectively disabled until changed. The following sporks currently exist on the network and serve functions as described below:
Governs the ability of Dash clients to use InstantSend functionality.
If enabled, masternodes will reject blocks containing transactions in conflict with locked but unconfirmed InstantSend transactions.
If enabled, superblocks are verified and issued to pay proposal winners.
Controls whether deterministic masternodes are required. When activated, the legacy masternode list logic will no longer run and non-updated masternodes will not be eligible for payment.
Enables automatic transaction locking for transactions with less than a specified number of inputs, and removes the legacy InstantSend fee. Allows any node to request the transaction lock, not just the sending node.
Enables the DKG process to create LLMQ quorums. This spork will be turned on once 80% masternodes are upgraded to v0.14, which will enable DKG and DKG-based PoSe.
When enabled, legacy InstantSend is superseded by LLMQ-based InstantSend, as described in DIP0010 LLMQ-based InstantSend.
Viewing spork status¶
spork show and
spork active commands issued in the debug
window (or from
dash-cli on a masternode) allow you to interact with
sporks. You can open the debug window by selecting Tools > Debug
Full release notes and the version history of Dash are available here: