Dash Roadmap

Financial freedom, built on masternodes

Dash was launched by Evan Duffield with the unique X11 hashing algorithm as its defining feature, and initial development focused on dynamic adjustment of mining difficulty, known as Dark Gravity Wave. This was soon followed by masternodes, providing a powerful and incentivized set of full nodes which form a backbone for the network and offer services to users. Sporks were released to help deliver a smooth release process of new features, without hard-forking the network, and finally PrivateSend was released to make Dash a truly fungible currency.

Building a foundation for the future

While initially based on the Litecoin project, Dash rebased to Bitcoin in early 2015. InstantSend, a method of locking transactions secured using the second-layer masternode architecture, was released soon afterwards. Work continued throughout the year to build a decentralized governance system and release up to 10% of the block reward to proposals presented to the network. The first superblock was mined on 7 September 2015, making Dash the world’s first Decentralized Autonomous Organization (DAO).

Blocksize and hashrate increases

Within 24 hours, the network completed a historic vote, reaching consensus to authorize developers to begin work on 2MB blocks, guaranteeing future capacity. Meanwhile, the hash rate multiplied rapidly as powerful mining hardware was released, increasing 16-fold over the course of the year. The management of the core team saw further professionalization and the introduction of quality assurance measures. Bitcore and Insight were released with Dash extensions, based on a network-funded effort to port the X11 hashing algorithm to JavaScript.

Stability, decentralization and accessibility

2017 saw Dash supported on major hardware wallets and two releases to optimize preparation of PrivateSend funds, and better manage the growing list of governance objects using a tool called Sentinel. Meanwhile, fees on all transactions were reduced by a factor 10 across the board, and ownership of Dash Core Group was transferred to an irrevocable trust, with the decentralized network itself named as beneficiary.

Named devnets

Named devnets allow for the creation of multiple independent devnets. Each one is identified by a name which is hardened into a “devnet genesis” block, automatically positioned at height 1.

Governance system improvements

Watchdogs have not been used since 0.12.2.x; instead, all required information about Sentinel is included in masternode pings. For this update, additional information was added to ensure that masternode pings weren’t changed by an intermediary node. All messages and logic related to watchdogs were removed. Improvements were made to the proposal message format and to proposal validation and processing, lowering network traffic and CPU usage. Handling of triggers was also improved.

PrivateSend improvements

Instead of requiring PrivateSend collateral to be N times the PrivateSend fee, any input which is greater than or equal to 1 PrivateSend fee (but less than or equal to 4) can now be used as collateral. Inputs greater than or equal to 1 PrivateSend fee but strictly less than 2 will be used as collateral with OP_RETURN outputs. This lowered the number of inputs a wallet needs to handle, and improved privacy by eliminating the case where a user accidentally merges small non-private inputs together. It also decreased global UTXO set size.

New Dash branding

Android and iOS versions of DashWallet were updated with the new branding guidelines, modernizing the look and feel of both apps.

Uphold integration (Android)

The ability to buy and sell Dash on Uphold through a web view within the Android app was also integrated, allowing for easier onboarding of users.

NFC support (iOS)

The ability to request a payment via NFC was added, allowing users to tap supporting payment terminals and wallets to receive payment information.

iPad support (iOS)

The ability to use DashWallet on iPad was added so users can pay and receive payments on their tablets.

New localizations

Many new languages and currencies were added so that users all across the world can use DashWallet in their native language and view exchange rates in their local currencies.

Automatic InstantSend

Dash Core v0.13 introduced Automatic InstantSend, where transactions with four or less inputs will default to InstantSend, at no additional charge to users.

Deterministic Masternode List

The Deterministic Masternode List provides a single source of truth for all transactions requiring validation by masternodes, such as InstantSend transactions. The list is fully derived from on-chain data. This ensures all nodes will come to the same consensus regarding the current state of the valid masternode list.

Special Transactions

Special Transactions provide new structures to enable non-financial transactions on the blockchain. This feature will lay the groundwork for future uses of the network on layer 2, like Blockchain Users.

Three masternode keys

Previously, masternodes had two keys for their masternode: owner (to prove ownership) and operator (to operate the masternode and use it to vote). The second key was broken into two: operator and voting, such that the masternode may delegate voting if they choose.

Unlock wallet with fingerprint

Users may now unlock their wallet using their fingerprint to allow for seamless use of the app.

iOS Library integration

DashWallet is now integrated with an iOS library that connects it to the Dash blockchain, and may in future be used by other iOS clients to do the same.

InstantSend receiving (iOS)

DashWallet can now confirm whether a received transaction was sent via InstantSend.

Price sourcing alignment

The price sources are now aligned between both the iOS and Android versions of DashWallet.

Long Living Masternode Quorums

Long Living Masternode Quorums provide for increased scalability of the network by improving consensus and expanding the universe of potential use cases for the network. These quorums drastically reduce the amount of messages required to validate transactions, and avoid each individual node on the network having to store consensus data in-memory until a transaction is mined. These quorums can be very large depending on the level of security required for the use case.

ChainLocks against 51% attacks

ChainLocks drastically reduce the risk of a 51% mining attack on the network. This feature allows a Long Living Masternode Quorum to sign a block and propagate a message to the network indicating that nodes should reject blocks at the same height that do not match the block specified by the quorum. This not only makes reaching consensus quick and unambiguous, it also makes chain reorganizations below that block impossible.

Uphold integration (iOS)

Users may transfer Dash from their Uphold account to their wallet within the app, and buy and sell Dash through an embedded webview.

Price sourcing improvements

Improvements were made to ensure exchange rates align with other frequently used Dash applications.

DashCore v0.14 support

Support for LLMQs and ChainLocks was added to the wallet, ensuring users would be able to benefit from added security and instantly respendable payments.

Public testnet (“Evonet”)

Dash Platform will be released onto a public testnet that developers can connect to to experiment with the functionality.

DAPI, Identities, Documents

Users will be able to connect to Evonet using the Decentralized API (DAPI); create test identities and names; and create, update and delete documents.

Naming service and DashPay contracts

Users will get to explore the Dash Platform Naming Service (DPNS) and DashPay contract.

Libraries

Several libraries will be available to developers, including the Dash SDK, DAPI-client, DPNS-client, and DPP libraries.

Developer documentation

A developer hub will offer helpful documentation and guides to the new functionality.

Uniform UX across Android and iOS

DashWallet’s UI will be unified across Android and iOS for a more consistent look and feel.

Dark mode support for iOS

DashWallet iOS will introduce a dark mode consistent with Apple’s guidelines.

Advanced security options

Users will be offered more flexibility in how they manage their security settings.

Easy access to commonly used features

Users will be able to quickly access key features from the home screen.

Backports for Bitcoin v0.15.2

This release will bring Dash up to date with Bitcoin v0.15.2, benefiting from a number of fixes and optimizations made to Bitcoin up through that release.

Basic QT Wallet UI update

Users will benefit from an updated UI on the desktop wallet to match the updated Dash branding. This includes updated colors and styles to match the style guide, removal of unnecessary elements to clean up the UI, and new icons.

Post stress test enhancements

This release will include several optimizations made based on the findings from the recent stress tests.

BIP70 Improvements

Improvements to the BIP70 feature allow for a more efficient payment experience at the point of sale.  Users/Merchants that implement this protocol benefit from refund options, the ability to split payments to multiple addresses and will have a more secure experience.

Block reward reallocation

The allocation of block rewards — excluding proposal funding — between masternodes and miners is changing from a 50–50 split to a 60–40 split over a multi-year transition period.

UI upgrade

The Dash Core experience is now more consistent across all supported operating systems in regards to fonts, graphics and screen layouts.

Concentrated signature recovery

The new signature recovery system initially sends signature shares to a single deterministically selected node, instead of propagating signature shares to every node until one has enough to recover the signature. This optimization is expected to reduce the load by several orders of magnitude.

Minimum protocol check

Proof of Service (PoSe) for Masternodes is enhanced by ensuring a minimum protocol version is running during DKG.

Network thread optimization

Network threading has been optimized by eliminating unnecessary repetition of loops through all nodes by implementing event polling (epoll) on Linux.

Bitcoin v0.16 backports

This release also introduces over 650 updates from Bitcoin v0.16 as well as some updates from Bitcoin v0.17.

Protocol versioning

Allows for the smooth rollout of breaking changes without wiping development networks.

Platform test suite

Platform test suite is a repo containing consolidated tests across the platform, makes testing and updating tests much easier across all components.

Binary document fields

Allows developers to use native binary types (e.g., Buffer, ByteArray) to store their data.

Document timestamps

Ability to record the creation or update time of any document stored on Dash Platform.

Improved distribution package

Support for config templating and multiple nodes in mn-bootstrap.

Default Dash identity name

Allows a user to specify a primary username for their Dash identity.

DPNS & identity DIPS

DIP11 Identities and DIP12 Dash Platform Name Service have been released.

Home Screen Improvements

The send and receive tabs were removed to create more space and to remove redundancy with the shortcut bar.

Small Screen Improvements

Labels were shortened and/or reformatted to avoid overlap with other UI components on small screens.

Recovery Phrase Improvements

A back button was added, support for non-English phrases was implemented, warning messages were updated

Chain Sync Improvements (iOS)

Numerous fixes and changes to the core data design and the Masternode and quorum list downloads.

The DashPay Alpha Program engages the community with DashPay wallet testing on Evonet.

Usernames

Users will be able to register themselves on the network and start sharing their personalized usernames with other Dash users.

User profiles

Users will be able to make their username more identifiable with a display name, picture and bio.

Connect with contacts

Users will be able to request contacts by username and create a list of users they want to transact with.

Pay and get paid by username

Users can exchange Dash with friends, family and merchants by username or cryptographic address.

Binary data storage improvements

Improvements to represent binary data as byte arrays as opposed to strings so data is stored more efficiently.  JSON Schema has also been extended with the ‘byteArray’ keyword, thereby allowing developers to more easily define binary properties in their data contracts.

Consensus rules for identities

Several changes were made to the underlying structure comprising an identity within Dash Platform

Non-Determinism in Block Processing

This was a known bug that prevented many developers from successfully starting nodes on Evonet.

Core height consensus

Establishing consensus between L1 and L2 chains based on the height of L1.

Instant Send identity funding

This allows identities to be funded by leveraging the speed of InstantSend.

State trees

Storage of data state in Merkle trees for use with light clients.

Platform Distribution Package

The distribution package (dashman f.k.a. mn-bootstrap) has been significantly updated in order to improve user experience and accommodate the new platform components.

Identity funding

Ability to fund identities without ability to double spend.

Chain Sync Improvements (iOS)

Further improvements were made to the chain sync process to prevent delays in sending payments.

Forgotten Recovery Phrase (iOS)

Improvements were made to help users who have forgotten one or two words of their recovery phrase to still attempt to recover their wallet.

Bug Fixes & UI Improvements (Android)

The UX associated to forgetting your PIN were implemented, updates were made to support a newer Android SDK (29), crashes associated to backing up to a file and importing a private key was made.

Tendermint seed nodes

A special type of node that provides peer information to other nodes to improve scalability.

Secure ST Acknowledgement

Improvements to address several possible attack vectors and for scalability on Mainnet.

Drive verbose logging

Add more logs for better clarity and troubleshooting of Drive behavior.

Improved error messages

Readable and informative messaging for proper error handling.

UI Improvements & Polishing

• Improvement: Upgrade to Testnet (Platform v0.17)
• Improvement: Search Network Users
• Improvement: Android / iOS UI Alignment
• Improvement: Username Validation
• Improvement: Save Profile Reminder
• Improvement: Bad Masternodes
• Improvement: Username Format (allow uppercase and hyphens)
• Fix: Wallet Lock Timer
• Fix: Incorrect Sync Status
• Fix: Sync & Crash Issues
• Fix: Import Private Key

100 member quorum

New quorum size to support asset lock special transactions.

RPC restrictions for platform

Security improvements when core is interacting with platform.

Bitcoin v0.17+ backports

Estimated 500+ backports from Bitcoin Core.

Identity funding with ChainLocks

Implement the second part of Identity Funding design that includes ChainLock proofs to better support client proofs.

Feature flags

Enable deterministically specific logic on the network to allow bug fixes and to enable new functionality without wiping the data.

Local network setup / environment

The mn-bootstrap local node doesn’t support chain locks and instant locks so we had to introduce fallback during development and on CI.

Verify signatures with Core

Improvements to Asset Lock Proofs (identity funding) to avoid duplicate logic and data it’s better to use Core which already implemented this logic and has all required data.

Remove Insight API

Remove insight as a dependency and transition functionality to DAPI to improve stability and to remove redundancy.

DashMate release

We continuously improve the Dash Platform distribution package (formerly known as mn-bootstrap) to make it more convenient and reliable. Since this version, we consider it mature enough to get a nice name and strongly encourage you to start using it to run testnet fullnodes and masternodes.

Improve CI

Slow builds and lack of available functionality in Travis CI significantly slowed down the development process. We migrated to Github Actions and implemented some caching tricks. New CI builds are much more flexible and running up to 10 times faster.

Validator Set Rotation

To archieve consensus on platform blockchain, a specific set of masternodes, called validators, verifies and signs blocks. Up to version 0.19, the validator set was static and hosted on nodes controlled by DCG. With version 0.20, Long-living Masternode Quorums (LLMQ) are used to dynamically distribute and rotate the validator set among all masternodes. This approach evenly distributes the load and makes the network much more secure and reliable.

Cryptographic Proofs

Previously, clients needed to use trusted full nodes to ensure the validity and integrity of data retrieved from the platform network. In this version, DAPI provides efficient cryptographic proofs alongside the platform data, which enables light clients (e.g. mobile wallets) to securely interact with Dash Platform.

Platform State Threshold Signing

Validators previously used non-aggregated EdDSA signatures of the platform state cryptographic digest in order to provide cryptographic proofs and guarantee network consensus. The number and overall size of these signatures made proofs resource-intensive for light clients to use. In version 0.20, the BLS threshold signing mechanism is used to produce only one signature, which mobile wallets and other light clients can easily verify.

Peer-to-Peer Layer Optimization

Previously, full nodes as well as validators relied on and verified all types of P2P messages. This means that full nodes also received network traffic containing messages only relevant to validators for achieving consensus. In the new version, full nodes no longer receive intermediate consensus messages produced by validators. Instead, validators produce only one message with a BLS threshold signature to propagate the resulting consensus decision to the remainder of the network. This heavily reduces network load as many messages no longer need to be propagated to full nodes, resulting in 99.5% less bandwidth usage.

Platform Metadata

Dash Platform now attaches additional metadata to DAPI responses, such as the current platform blockchain height, as well as the synchronized core blockchain height observed and agreed upon by all nodes participating in network consensus. Since the platform and core blockchains are asynchronous, platform uses this core height to ensure all platform nodes have a deterministic view of the core network state.

Strict and Secure Data Contract Validation

The new version of Dash Platform Protocol updates the JSON Schema specification used to define data contracts to the most recent 2020-12 version, and employs strict validation rules to prevent potential user errors in data contracts submitted to the network. A special regular expression engine is also employed to mitigate ReDoS attacks.

Robust JS Wallet Synchronization

Previous versions of the JS Wallet library did not always receive all requested transactions and instantlock messages from DAPI during synchronization. This has been resolved in version 0.20.

Dashmate Improvements

The latest version of Dashmate contains 20 fixes and improvements. The most significant of these were designed to make setting up local development networks more convenient and reliable, as well as performance improvements and Windows support.

Liquid Exchange Integration (Android)

Integration of the Liquid Quick Exchange into the wallet to allow for the purchase of Dash with Visa credit cards from within the Dash Wallet.

BIP70 Improvements

Improvements to the deep link UX so that there is a seamless user experience between the newly released DashDirect app and other apps that use this protocol.

Implemented BIP69

This aligns with a more common standard of input/output organization that provides for better anonymity.

Passphrase Improvements

UI improvements to better educate users of the importance of their passphrase and prevent users from taking screenshots of their phrase.

Chain Sync Improvements

UI improvements to the status and backend changes to improve the performance of the sync.

Maintenance

Multiple bugs and UI improvements associated to Uphold, fingerprint authentication, UI navigation, and the auto-logout feature, and some code refactoring in preparation for the DashPay upgrade.

Send Invitation

To simplify getting your friends and family on the Dash network, you can send them invitations so they have everything they need to create their own username.

Accept Invitations

As a brand new user who doesn’t have any Dash, an invitation will allow them to create their username right away without needing to wait to acquire Dash first.

Error message improvements

Implementation of error codes and more descriptive messages so that client applications can handle them better and so bugs are easier to investigate.

Design robust state tree structure

At the moment, we store state in different merk trees which adds some overhead for memory and disk. It also requires very complex logic to ensure atomicity and to handle cross-database transactions which are not implemented.  A new more robust, and secure state tree design will be defined.

Design document secondary indices

As part of the new state tree design, MongoDB will be replaced.

Distribute testnet nodes

Testnet will be updated to include nodes across multiple data centers to simulate real-world issues with latency and performance which could impact scaling.

Upgrade Process

An improved upgrade process will avoid the need to wipe L2 data allowing for safe transition between protocol versions.

GroveDB initial release

The first of its kind, a hierarchical authenticated data structure (HADS) based database relying on an innovative provable data storage system. This will allow features not possible with any other database currently in existence. The first release will offer secondary indices and will hold cryptographic proofs for the integrity of stored content.

Ability to update data contracts

This allows contract schemas to be modified without data loss or the need to create a new contract. This is a clear and obvious differentiator between Dash and smart contract networks which do not have the ability to do this.

Masternode identities

When a Masternode has a Dash Identity with a balance attached, the Masternode owner can receive rewards for their participation in Platform consensus. This gives an additional revenue stream for Masternode owners.

Identity key purposes and security levels

Future Dash Platform features will require various security levels. Performing a sale of a very valuable digital asset should require a very high-security level while publishing cat pictures probably would not. With this feature, users can keep the highest security level keys on their hardware wallet, yet perform less critical actions directly from their phone.

Multi-package repository

To speed up the development and build process, Platform components code was migrated from standalone repositories to one multi-package repository. This mono-repository approach significantly reduces routine operations that need to be done during development.

Quorum rotation, stronger IS security

Improves the distribution of quorum load across masternodes while also expanding the security of InstantSend. This is accomplished by only changing a subset of masternodes in a quorum during quorum member selection while also limiting the number of quorums each node is selected for at once.

Proposal fee reduction

Reduced the proposal fee from 5 DASH to 1 DASH in order to make the governance system more accessible. This change was driven by a masternode approved proposal.

Added new QT governance UI

Added a Governance tab to allow Dash Core Qt users to access governance proposal details more easily.

Initial Enhanced Hard Forking implementation

Implemented a new special transaction and aspects of DIP23 necessary to support the full enhanced hard fork mechanism to be released in the subsequent version of Dash Core.

Deterministic InstantSend locks

Introduced deterministically verifiable InstantSend locks (DIP22) to better support the Platform identity system. This allows InstantSend transactions to be verified in the future rather than just ephemerally.

BTC v0.18/v0.19/v0.20 backports

Backport completion for Bitcoin Core v0.18 increased from 83% to 86% and v0.19 completion increased from 41% to 53%. Additionally, 18% and 10% of backports were completed for v0.21 and v0.22 respectively.

External security audit

Dash Core Group has officially engaged with a professional auditing firm to perform a security audit on the Core codebase.

Ability to update an Identity (see DIP11)

Remove the functional gap regarding the specifications of DIP0011. This includes implementation of an Identity Update State Transition, the introduction of Identity Public Key security improvements, added functionality required for credit withdrawals, and the implementation of an Identity key-ownership proof.

Initial Storage Fee Calculations

An incentivizing fee model that will compensate Masternodes for processing and storage costs as well as prevent spam. The implementation of the new fee calculation system is based on the operations required to process state transitions and the amount of data it stores on the Masternode network. Although the storage fee calculation with the new model is precise, processing fees are still a subject for improvement. Fee refunds for deleting data will also be implemented in the upcoming version.

State Transition Fees Distribution

A system where Platform fees are collected in pools to be distributed to Masternodes over time. This design incentivizes Masternodes to continue hosting and to avoid letting their node go offline. State Transition storage fees are distributed to every Epoch (~18 days) up to 50 years in the future. When a new Epoch starts, Masternodes are getting rewards for providing service in the previous Epoch.

Platform credit withdrawal into Dash

Platform credits are exchangeable for Dash. Masternodes will have an easy way to withdraw their Platform rewards.

Headers First Synchronization

Improved security and reliability for chain synchronization in Dash JS wallet. JS Wallet will become a real SPV client that performs full chain synchronization and verification by asking randomly-selected Masternodes to return the requested chain data.

Dash Platform Bench Suite

To measure performance of Platform components, this version introduces a benchmark tool. This tool is deeply integrated with Platform blockchain runtime and provides convenient instruments for developers to experiment and track performance over time.

Dash Platform Protocol in Rust

Porting DPP to Rust makes it more secure and performant. It will also make block processing faster. To integrate Rust DPP into JS components we provide WASM DPP. This is the first step towards porting Platform to Rust. JS was nice for experimenting and prototyping but now we need something more sustainable.

Same Block Execution

A limitation inherited from the Tendermint project on which our consensus engine was originally derived, block signatures only would sign the state of the previous block as well as all state transitions of the current block. Hence to get proven data from DAPI you would need to wait for the next block commitment. This was incompatible with our desired proof system and storage system. This improvement also significantly reduces the load on the network and decreases the time needed to insert data into Platform, resulting in better UX.

Credit Withdrawals

Currently, you can convert Dash to Platform Credits by creating or topping up an Identity. Credits are mainly used to pay state transition fees. Masternodes get their rewards for hosting Platform in Credits (block rewards and ST fees). Withdrawals allow Masternodes and other Identities to convert their Credits back to Dash.

Efficient Data Serialization

Dash Platform Protocol (DPP) previously used the CBOR encoding mechanism that implements schemaless data serialization. Since all data on Platform is stored in predefined structures, there is no need to store structure information as well. By only storing values we dramatically reduce the size of serialized objects.

Fee Refunds

When a user adds data to Platform they pay for permanent storage. However, not all data stored in Platform must be permanent. Users can define in data contracts the ability for documents to be updated or removed. The introduction of fee refunds allows users to get credits back when they delete data.

Identity v2

An Identity consists of various data such as its balance and a collection of public keys used for various purposes and security levels. The new Identities storage implementation allows updating or fetching of only specific or multiple parts of Identity. This reduces state transition fees and the load on the network.

Total Credits Verification

A new GroveDB sum trees feature allowed us to implement a protection mechanism against inflationary bugs on the blockchain. This feature added sums to nodes of a specific type of Merkle AVL tree. In this tree, root nodes hold the sum of all integer values in the tree. Any time a value is added, removed, or updated in a sum tree, every parent node and hence the root’s “sum value” is updated. The credit verification mechanism compares every block of all credit balances in the storage with the expected amount of credits in the system. This prevents inflationary attacks that would mint new credits or tokens outside of the predefined supply.

Masternode voting identities

This is a component to enable future governance features on Platform.

Decentralized API with HTTPS

From this version onwards, DAPI requests are served via HTTPS to allow for building applications for browsers.

High Performance Masternodes (HPMN)

A High Performance Masternode is a new type of Masternode which will be used to serve the network by participating in consensus on both the Dash Platform chain and the Dash Payment (Core) chain. In this system, the standard Masternode would continue serving only the Dash Payment chain. HPMN’s will have greater requirements than a standard Masternode such as 4k Dash collateral and higher performance specs as they would be running two chains instead of just one.

BLS v1.0 implementation

BLS signature library update for the new signature scheme for standards alignment and improved security.

Bitcoin v0.19/v0.20/v0.21/0.v22 backports

Backports from Bitcoin Core from BTC v0.19/v0.20/v0.21/v0.22.

Resolve v19 Hard Fork Issues

One of the goals for the v19 Hard Fork was to activate basic BLS scheme and start using it in various on-chain and p2p messages. The motivation behind this change is the need to be aligned with IETF standards. Unfortunately, a few edge cases were missed in our functional tests and were not caught on testnet either. v19 activation attempt on mainnet hit one of these edge cases and mainnet stopped producing blocks. As an intermediate solution v19.1.0 was released which delayed the start of the signaling for the v19 Hard Fork until June 14th.

To resolve these issues we had to rework the way BLS public keys are handled including the way they are serialized in the internal database. This made it incompatible with older versions of Dash Core, so a db migration path was implemented for all recent versions.

Improve migration and historical data support on light clients

As a side-effect, the solution implemented to resolve v19 Hard Fork issues opened a path to simplify v19 migration for mobile wallets.

With previous implementation mobile wallets would have to convert 4k+ pubkeys at the v19 fork point and that can easily take 10-15 seconds if not more. Also, after the v19 Hard Fork, if a masternode list is requested from a block before the v19 Hard Fork, the operator keys were coming in basic BLS scheme, but the masternode merkleroot hash stored in coinbase transaction at that time was calculated with legacy BLS scheme. Hence it was impossible to verify the merkleroot hash.

To fix these issues a new field nVersion was introduced for every entry in mnlistdiff p2p message. This field indicates which BLS scheme should be used when deserialising the message – legacy or basic. nVersion of the mnlistdiff message itself will no longer indicate the scheme and must always be set to 1.

Improve mixing support on light clients

Recent changes to dsq and dstx messages allowed mobile clients that get masternode lists from mnlistdiff message to determine the masternode related to these messages because the proTxHash was used instead of the masternodeOutpoint. Once the v19 Hard Fork activates the signature of dsq and dstx messages will be based on the proTxHash which should make it possible for mobile clients to verify it.

Keep ChainLocks enabled without signing new ones

Before this version ChainLocks were either enabled or disabled. Starting with this version it’s possible to set SPORK_19_CHAINLOCKS_ENABLED to a non-zero value to disable the signing of new ChainLocks while still enforcing the best known one.

No one person or organization has control over when v19 will activate; it will occur after a specified number of masternode owners and miners have upgraded to the latest version.

Masternode block rewards

Masternode block rewards will be split between normal Masternodes and High-Performance Masternodes (HPMN). The HPMN part will be accumulated in credits and distributed over time between nodes as incentivization to serve Platform. Nodes will get rewards every Epoch (~18 days) if they provide the services (propose new Platform blocks).

Processing fees and adjustments

This is the addition of more finite processing fees and the adjustment/revisiting of existing numbers to make sure all costs are covered adequately and fees are calculated properly.

Protocol upgrade

Test and improve protocol upgrade processes to optimize the implementation of breaking changes for different levels of the system.

NFTs support

Prepare Dash Platform for storing and maintaining Non-fungible tokens. While using Platform storage mechanism, provide a way to keep NFT data also on chain.

Instrumentation

Implement metrics for Platform components required for network monitoring including further stress tests.

Internal Security Test

Security experiments and tests by DCG.

Stress Tests

Stress tests are performed with a stress test suite on a dedicated network.

Treasury expansion

Prior to DashCore v20.0, 10% of block rewards were set aside for the Dash DAO treasury which funds development and other network efforts. Once the DashCore v20.0 hard fork goes into effect on mainnet, the treasury system allotment will increase to 20% of block rewards to align with the proposal approved in September. Miner and masternode rewards will change to 20% and 60% respectively upon activation of the change.

Sentinel deprecation

Sentinel functionality has been integrated directly into v20.0, so it will no longer be necessary for masternodes to run the standalone Sentinel application. Several RPC commands have been updated to prevent conflicts between DashCore v20.0 and existing Sentinel installs. It is recommended to remove or disable Sentinel after updating masternodes to v20.0.

Asset lock special transaction

Introduced a new type of special transaction, “Asset lock”, to support platform identity funding

Masternode reward reallocation

The masternode reward reallocation (MN_RR) hard fork, first included in Dash Core v20, will be activated after v21 is adopted by masternodes. This hard fork enables the major feature included in this release: Masternode Reward Location Reallocation. The activation will also initiate the launch of the Dash Evolution Platform Chain.

Reward reallocation and evonode payments

Once the MN_RR hard fork activates, part of the masternode subsidy in the coinbase will be moved into the Credit Pool (i.e., to Platform) each time a block is mined. Evonodes will then receive a single reward per payment cycle on the Core chain – not rewards from four sequential blocks as in v19/v20. The remainder of evonode payments will be distributed by Platform from the credit pool. This is to incentivize evonodes to upgrade to Platform because only nodes running Platform can receive these reward payments.

Mainnet spork hardening

Dash introduced sporks in 2014 as a way to provide smoother upgrade transitions than hard forks. While this innovation has been useful, the network has matured to a point where they are no longer necessary on mainnet due features like enhanced hard forks. Consequently, this version hardens all sporks on mainnet. Sporks remain in effect on all devnets and testnet; however, on mainnet, the value of all sporks are hard-coded to 0, or 1 for the SPORK_21_QUORUM_ALL_CONNECTED spork. These hardened values match the active values historically used on mainnet, so there is no change in the network’s functionality.

Dash Platform Pre-Mainnet Validation

Various network experiments, revisiting codebase, preparations and potential bug fixes for mainnet release with tight collaboration with Dash Community (taking usage of Community projects utilizing Dash Platform).

Start of Mainnet rollout

The first mainnet roll out of Platform will be bundled with the roll out of Core v0.21.  The Dash Network will be encouraged to complete their upgrades as soon as possible.

EHF Resigning

This fixes an issue in EHF resigning, where masternodes would not resign for EHF if that had previously been in a EHF signing quorum. As a result, the threshold was unable to be met.

Activation Readiness

These versions were to ensure a successful activation under specific conditions that were being observed.  These were a mandatory upgrade for all Evonode operators. Contrary to other activations this version will activate the Platform chain as soon as 67 Evonodes in the Genesis quorum have upgraded and are properly configured.

Dash Platform Activation

No one person or organization has control over when the Platform protocol will activate; it will occur after a specified number of Evonode owners have upgraded.  

DPNS

When this contract is created, it will allow for usernames to be registered on the network.

DashPay

When this contract is created, it will allow username payments to be submitted on the network.  

Get multiple identity balances in one query

This will allow for DAPPs to more easily interact with multiple identities.

Withdrawals

This will allow masternode owners to have their L2 credits converted to Dash rewards

Release Notes

https://github.com/dashpay/platform/releases/tag/v1.5.0

Android DashPay Wallet

The release of the DashPay mobile wallets will allow users to upgrade from Dash Wallet and easily create contested and non-contested usernames, make username payments and allow Masternode owners to vote on username requests.

Release Notes

https://github.com/dashpay/platform/releases/tag/v1.6.0

Release Notes

https://github.com/dashpay/platform/releases/tag/v1.7.0

Compressed block header requests

The maximum number of compressed block headers that can be requested at once has been increased from 2000 to 8000. This change is expected to reduce blockchain synchronization times for clients using compressed block headers since they will be able to obtain headers faster.

DSQ message

To reduce bandwidth usage, the DSQ message is broadcast using the inventory system instead of relaying to all connected peers. While this should reduce the bandwidth needs for all nodes, the effect will be most noticeable on highly connected masternodes.

Platform withdrawals

Platform withdrawal processing has been updated to accept withdrawal transactions from more Platform quorums. Previously, transactions were only accepted if signed by one of the first two active quorums. With this change, withdrawals can be signed by any of the valid quorums.

Onion Nodes

To improve censorship resistance and mitigate network partitioning risks, Dash Core nodes connected to the onion network now aims to maintain at least two outbound onion connections and protect these connections from eviction. As a result of the low percentage of gossiped addresses being onion nodes, it was often the case where, unless you specify `onlynet=onion`, a node would rarely, if ever, establish any outbound onion connections. This change ensures that nodes accessing the onion network maintain a few onion connections. As a result, network messages will continue to propagate across the network even if non-onion IPv4 traffic is blocked, reducing the risk of partitioning. Note: only nodes connected to the onion network are affected by this update.