Dash Sets November 9 for Its V24 Hard Fork Signal: Masternodes Have a Week to Upgrade

Dash Core has fixed the mainnet start date for its V24 network upgrade: signaling opens at 00:00 UTC on November 9, and the earliest activation is around November 28.

The release schedules two deployments, v24 and evo_shares. Only one of them can activate with this release.

Dash’s next hard fork now has a start date. On October 29, Dash Core developer pasta merged the change that sets the mainnet schedule. Every masternode on the network now has a week to upgrade.

The change sets the start time for two deployments, v24 and evo_shares, to November 9, 2026 at 00:00 UTC. Both have the same timeout: November 9, 2028. A detail in the commit message is easy to miss: “v24 nodes do not sign the evo_shares signal, so only V24 can activate with this release.”

The fork brings shared masternode collateral, split payouts, extended network addresses and changes to how Dash Platform withdrawals work. The upgrade deadline applies to everyone, but the EvoNode-specific part will have to wait for a later release.

What Was Merged On October 29

The schedule is set in two pull requests: #7973 for the main development branch and #7969, which backports it to the v24.0.x release line. Each replaces placeholders in Dash’s chain parameters with fixed dates.

The deployment parameters:

• Start: 1794182400, Monday, November 9, 2026, 00:00 UTC.
• Timeout: 1857340800, Thursday, November 9, 2028, 00:00 UTC. That mirrors MN_RR, Dash’s previous mainnet hard fork.
• Version bits: bit 13 for v24, bit 14 for evo_shares.
• Signaling window and threshold: 4,032 blocks, starting at 80% and falling to a floor of 60%. These are the same values used for V20 and MN_RR.

The v24.0.0 release notes describe the release as mandatory for all nodes. The newest tag in the repository is v24.0.0-rc.5, cut on October 29, the same day the schedule was merged.

How Masternodes Turn The Switch

V24 uses Dash’s Enhanced Hard Fork mechanism, DIP-0023. It works differently from Bitcoin-style miner signaling: the process starts with masternodes, not miners.

The release notes describe three steps:

1. Masternodes sign a signal. Once the network’s median time passes the start time, masternodes running v24 sign an EHF signal with the LLMQ_400_85 quorum. That quorum requires 85% of its members to be running v24.
2. Miners start signaling. After the masternode signal is mined, miner signaling begins at the next 4,032-block window boundary.
3. Lock-in, then activation. If a window reaches the threshold, the hard fork locks in, and it activates one window later.

That is why the deadlines differ by node type. Masternodes must upgrade before November 9, because the fork can’t begin until enough of them sign. All other nodes must upgrade before activation, or, in the notes’ words, they “will follow an invalid chain.”

There is also a separate reason for masternodes to upgrade quickly. V24 raises the minimum masternode protocol version from 70240 to 70242. During distributed key generation, quorum members connected over the older protocol “are considered to have a bad connection and are voted bad, which leads to PoSe penalties.” Masternodes that delay could be penalized by Dash’s proof-of-service system, even before the fork itself.

The November 28 Arithmetic

The release notes set out the earliest possible schedule, assuming 2.5-minute blocks.

Signaling opens on November 9, when mainnet is expected to be near block 2,569,500. The first window boundary after the masternode signal is block 2,572,416, around November 14. If that window reaches the threshold, V24 locks in at block 2,576,448 and activates at block 2,580,480, around November 28.

Each 4,032-block window lasts about seven days. The notes stress that November 28 is the best case: “every window that misses the threshold delays it by about one week.” The threshold also falls over time. It starts at 80% (3,226 of 4,032 blocks) and steps down each window to 60% (2,420 blocks) after 10 windows. If adoption is slow, activation slips, but it doesn’t fail outright.

Shared Masternodes And Split Payouts

Most of what V24 activates concerns how masternodes are owned and paid.

Shared collateral. After activation, a version 3 ProRegTx (masternode registration) can carry a collateral share table:

• 2 to 8 participants fund a masternode’s collateral together in a single registration.
• Each participant records a fixed contribution, a refund address and a share owner key.
• The owner reward is split in proportion to each contribution.

New transaction types to manage shared nodes:

• ProDisTx: dissolves a shared masternode and refunds each participant’s principal. If one participant exits during an agreed early period, they pay a penalty.
• ProUpShareTx: lets one share owner update their reward address.
• ProUpSharedRegTx: changes operator or voting keys, with every share owner signing.

Multi-party payouts. A masternode can split its owner reward among several addresses, set in basis points.

Extended addresses. Masternodes can list their core P2P, Platform P2P and Platform HTTPS endpoints explicitly, using version 3 provider transactions. This applies to regular masternodes and EvoNodes alike, and doesn’t depend on evo_shares. After activation, an EvoNode service update must be version 3. Old version 2 updates are rejected with bad-protx-version-disallowed.

Platform changes:

• Withdrawals: they get a stable transaction ID.
• Withdrawal limits: a flat 4,000 DASH cap is replaced by a relative limit, 20% of the credit pool with a 2,000 DASH floor.
• Platform addresses: they are introduced at the consensus level, though sending to them stays non-standard on mainnet for now.

Why evo_shares Is Scheduled But Not Signed

evo_shares covers the EvoNode versions of the features above. Until it activates, EvoNodes can’t register with shared collateral or use more than one owner payout. Those transactions are rejected with bad-protx-shares-evo and bad-protx-payouts-evo.

v24.0.0 doesn’t sign the evo_shares signal. According to the release notes, “a later release (v24.1) is expected to sign it once Dash Platform supports EvoNode shares and payouts.” Both deployments still get identical dates now, so that the later release “can activate evo_shares without another mainnet parameter change.” So shared ownership arrives for regular masternodes with this fork, and for EvoNodes only after a later release.

What Operators And Builders Need To Do Now

For masternode operators:

• Upgrade to v24 before November 9.
• Keep an eye on the final v24.0.0 release, since the newest tag is still a release candidate.
• Don’t regenerate configuration from scratch. Nodes running with -txindex=0 must now also set -disablegovernance, or they refuse to start.

For regular node operators, exchanges and wallets: upgrade before activation, at the earliest around November 28. The first start can take 20–40 minutes or longer on nodes with address, spent or timestamp indexes, because those indexes move to their own databases.

For developers: anything that parses or builds provider transactions, such as explorers, SPV libraries and external wallets, must handle the new version 3 format before activation.

V24 is one of Dash’s larger consensus upgrades in years. The date is set, but the fork only goes ahead once masternodes have upgraded and signed the signal.

Disclosure: This is not trading or investment advice. Always do your research before buying any cryptocurrency or investing in any services. 

Follow us on Twitter @themerklehash to stay updated with the latest Crypto, NFT, AI, Cybersecurity, and Metaverse news!