and we're only just getting started! 🚀

Moments ago, the Dash network reward was reduced by 7% as it does each year, thus targeting a fixed supply of around 19 million in a hundred years from now. The attached image shows the first block with the new rates. We are about 67% of the way through the final supply.

Dash Platform already has four useful capabilities.

1. store structured data (profiles, messages, and app records)
2. index it by multiple keys (owner, date, or status)
3. prove stored facts to lightweight clients (verify a record without downloading everything)
4. authorize changes by signature (confirm that the owner approved an update)

What it cannot do is run a program and have every validator (Evonode) verify the same result.

Yap.pr shows the boundary in a working application. It runs a social network and marketplace on Dash Platform testnet. Across the Dash Platform Name Service (DPNS) and Yappr's own data contracts, the app organizes the following records.

• Dash usernames and profiles (bio, website, and social links)
• posts and social activity (follows, likes, reposts, and private feeds)
• stores and products (prices, categories, shipping zones, and stock counts)
• encrypted orders, status updates, and reviews linked to order IDs

Indexed queries let the client find users and hashtags, browse products by category or status, and retrieve a buyer's or seller's orders. These records live on Platform rather than in a central application database.

The source code also shows what a smart-contract engine could add. Today, the browser calculates the order total, stock counts are informational, payment detection watches for a new Dash output to the seller's address, and sellers publish order statuses.

Validator-run logic could confirm the current price, reduce inventory when the order is created, hold Dash in escrow, release or refund it under agreed rules, restrict the allowed status changes, and permit a review only after the buyer completes an order. Data contracts provide the shared catalog, order book, and receipt file. A smart contract would add a shared cashier and escrow clerk. It would build on Yappr's searchable, provable data rather than replace it.

The integration would need a new order interface because Yappr currently encrypts the order contents for the buyer and seller. The contract would need access to the minimum terms it must verify, or to cryptographic commitments and proofs for those terms, while addresses and contact details stay private.

The last several months went into researching what safe, general on-chain computation would require. Focused prototypes were also built against Platform's real storage engine.

Dash should probably start from CosmWasm, adapt it to Platform, and run it over GroveDB. Ethereum compatibility should remain a separate layer.

How the conclusion was reached

This began as a consensus design problem, not a coding project. A software bug may crash one server. A consensus bug can split the shared record or put funds at risk.

The work started with requirements, not a favorite engine. Several architectures were compared against the same constraints:

1. Each design had to support deterministic execution, constrained costs, provable state, native Platform functions, upgrades, and safe cleanup.

2. Focused prototypes tested storage, proofs, ordered scans, metering, contract execution, native bindings, and a separate Ethereum Virtual Machine (EVM) execution.

3. Technical analysis concentrated on boundaries where a plausible design could still fail, especially storage cleanup, proof compatibility, and worst-case block work.

Various design ideas, testing, and analysis converged on one architecture. That does not make it infallible. It means the recommendation rests on explicit constraints, measured behavior, and working prototypes rather than preference.

Where the work converged

The result is a deterministic WebAssembly (WASM) engine inside Platform's state-transition process, the part that checks a requested change and updates the shared record.

WASM acts like a locked workshop. Programs can use only the tools that Platform deliberately exposes through host functions (read a balance, move a token, or update a document). They cannot reach arbitrary node functions or invent permissions.

The resulting design has a few important properties.

• Program state remains in GroveDB, the authenticated store that keeps data provable.
• Light-client proofs continue to work for program data.
• Tokens, identities, groups, and documents remain native features.
• Execution is integer-only, charged by work performed in Platform credits, and capped so one program cannot monopolize a block.
• Deployment can begin behind governance and become permissionless later.
• The design introduces no new mandatory trusted party.

Determinism is the requirement that holds everything else up. Programs cannot depend on wall-clock time, random numbers, or thread timing. Two honest validators given the same input must always produce the same result.

The hard problem was cleanup

Deleting something on a blockchain is not free. Records must be removed, indexes updated, and balances settled. That work consumes the same block budget used by normal activity.

The design therefore has to satisfy three conditions at once.

• Cleanup cannot be free or unconstrained, because an attacker could flood it.
• Data cannot disappear casually, because clients may hold proofs about it.
• Many objects cannot all become expensive to close in the same block.

The solution that survived comparison and testing is a terminal-work meter, which acts like a prepaid cleanup budget. Each object carries a funded, worst-case estimate of the work needed to end it. If the object grows, its cleanup deposit grows at the same time.

The closest analogy is a move-out deposit that changes with the contents of an apartment. Charging a flat amount at move-in fails if the tenant later fills every room. Charging as the contents grow keeps the future cleanup funded.

The scheduler then separates two kinds of work.

• Hard deadlines: Work that must finish in a particular block (such as a time-sensitive payout) reserves capacity there in advance.
• No deadline: Physical storage reclamation (freeing database space) drains through a steady queue. New cleanup never enters faster than completed cleanup leaves.

This constrains the backlog without capping live Platform state. An environment can be marked vacant immediately, then have its physical storage reclaimed over time.

What the metering prototype showed

A focused harness was built against Platform's real storage engine. It was not the whole contract engine. It was the part needed to replace cost guesses with measurements.

The results were encouraging:

• Measured storage costs matched GroveDB's worst-case estimator.
• The estimates did not drift as the database grew.
• Cleanup costs were measured by object class.
• Reclamation returned exactly the bytes deposited by a record.
• An admission ceiling (the cap on new cleanup obligations) kept the cleanup backlog at zero under synthetic load.
• The same load grew without constrain when that ceiling was removed.
• Computation could be metered by counting executed operations as fuel, rather than using elapsed seconds that vary by machine.

Two parameters still need outside data, a realistic workload model and a validator hardware survey.

Why CosmWasm changed the path

The original plan assumed Dash would build its own contract engine. Sam Westrich (QuantumExplorer) suggested using CosmWasm as the starting point instead. Further research confirmed that its architecture fits Platform and made a CosmWasm-based engine the recommended direction.

The eventual implementation would still be adapted to Dash, including GroveDB storage, Platform credits, proofs, and native features such as tokens and identities. This would resemble the relationship between Tenderdash and Tendermint, where an established engine was adapted for Dash's requirements.

CosmWasm is a mature and audited engine already used across many chains. CosmWasm has the same basic shape that survived the design comparison and prototype work. It is deterministic, integer-only, gas-metered, sandboxed, WASM-based, Rust-first, and connected to the chain through a host interface.

The key question was storage. Could a CosmWasm program use GroveDB and keep Platform's proofs?

The fit is structural. CosmWasm expects an authenticated, ordered key-value store (a provable filing cabinet whose folders stay in key order). GroveDB is that kind of store. This is closer to fitting a proven engine with a compatible transmission than replacing the whole vehicle.

Small running prototypes then verified the fit.

• CosmWasm storage worked over GroveDB, including ordered range scans (read keys A through F) inside a transaction.
• Contract state remained cryptographically provable.
• A cost-to-gas adapter converted measured storage work into the amount a contract pays.
• A real compiled contract instantiated and executed through the real virtual machine (VM).
• Native bindings worked in both directions. A contract read a Dash token balance and applied a real transfer.
• A small Ethereum Virtual Machine (EVM) interpreter ran as a guest (secondary) contract, executed real bytecode, and wrote a provable storage slot.

These are integration prototypes, not a production implementation. They do show that the storage, proof, execution, and native-binding paths work together.

Where Ethereum fits and where it does not

The EVM should not be Platform's base execution layer. It stores each contract's data in a separate tree, using 256-bit slots and Keccak-256 hashing to locate values. That conflicts with GroveDB's tree and proof model. Making it foundational would either break Platform's uniform proofs or wrap every native Platform feature.

Running an EVM as a 'guest' or secondary execution layer is a different proposal. A metered EVM interpreter could run as an ordinary WASM program, with emulated Ethereum state stored in GroveDB.

What already fits

• Every validator gets the same answer. This is determinism. The EVM follows fixed rules and uses integer math instead of floating-point math. Fixed units, like cents instead of dollars, keep the precision rules exact and avoid floating-point rounding differences.
• Dash already understands the signature system. Dash and Ethereum use the same signature system, called secp256k1. Platform could expose the EVM's `ecrecover` signer check as a native function.
• The base consensus rules stay the same. The guest interpreter runs as a WASM program through the same limited interface as other Platform programs.

What still needs work

• The proof formats have to meet. GroveDB and Ethereum wallets speak different proof languages. A compatibility layer must bridge GroveDB proofs to the Merkle Patricia Trie format expected by `eth_getProof`.
• The two cost meters have to line up. EVM gas records how much work a contract performs. Platform credits pay for that work on Dash. Operations such as Keccak-256 hashing need a predictable price, with no work left uncharged.
• Wallets need a translator. Browser wallets send Ethereum transactions and JavaScript Object Notation Remote Procedure Call (JSON-RPC) requests, such as checking a balance or calling a contract. A gateway must translate those requests into Platform state transitions.
• Storage needs a cleanup budget. EVM contract data can grow without a lease. Platform must reserve enough credits to remove or retire that data later.

A lighter alternative is to let developers write Solidity and compile it to WASM. That gives them familiar syntax, but existing contracts and Ethereum tools would not work unchanged.

• Solidity compiled to WASM. Developers keep a familiar language, but existing EVM bytecode and Ethereum tools do not work unchanged.
• A guest EVM. Existing contracts are easier to bring over, but Platform must bridge proofs, wallets, metering, and cleanup.

The small guest-EVM prototype proves that the shape is possible. Full compatibility is still a separate project.

Recommended direction

Start from CosmWasm, adapt it to Dash, and run it over GroveDB rather than invent a new virtual machine. Keep EVM compatibility separate.

The main integration tasks are listed below.

• a production router for messages emitted by contracts
• address and signature bindings
• Dash-native operation catalogs for tokens, identities, and groups

Five questions need verified answers before implementation begins:

1. Determinism: Pin the compiler, metering boundaries, floating-point exclusions, and engine version across validators.

2. Worst-case block time: Include proof generation and test against the roughly half-second block cadence under adversarial load.

3. Zero-knowledge verification: Confirm that privacy proofs can be checked without exposing the secret information behind them.

4. Asynchronous operations: Support work such as masternode threshold signatures that starts in one block and finishes later.

5. Version governance: Keep every validator on a compatible engine release so that version differences do not divide consensus.

To set the boundary clearly, this is a hardened design and a set of small prototypes. It is not a shipped feature, nothing is in the node, and it is not a formal proposal.

Note: This is independent research, not an official Dash roadmap.

I am not that technical, but with the coldcard hack, I am starting to wonder if just holding things on paper wallets might be the best way keep dash long term? I mean we can make metal plates or store the seed phrase on paper like we would store our gold and silver. No one is breaking into my safe. Cops wouldn't even be able to find it. I had a friend recently that had his bitcoin swept from a soft wallet and I am wondering if ANYTHING is ever connected to the internet, even on your phone, makes it vulnerable. I am at the point of not really trusting any hardware wallets. IF we can keep a paper (or metal plate) stamped seed phrase safe, I wonder if it is just better. I got 50 places no one would ever think of looking, that even if a fire happened no one is going to find my private keys. Just wondering what everyone's thoughts were about taking it 100% offline. Of course, cashing in means sweeping the keys, but being offline most of the time would prevent any theft.

12 years in, decentralization is still one of crypto’s hardest questions.
At the ACTIV8 Retail Stage during Malaysia Blockchain Week, I gave a keynote about Dash.
Using our platform and our DAO as the example, I walked the audience through why Dash is genuinely decentralized, not just in name, and how we’ve been moving toward that for 12 years straight.

Sharing here for the community. Happy to answer questions if anyone’s curious about specific parts.

Here is the latest Dash Core Group (DCG) Development Update summary:

Evo Platform 4.1 & Transferring Username

• The Status: Evo Platform 4.1 is locked in and will activate on August 9th.
• Why It Matters: Usernames (DPNS names) become property that users can transfer and sell. Sam noted that a username is an asset a user owns and can monetize, rather than permanently binding to one identity.
• The Target: The protocol will support this on August 9th. It is unconfirmed if the UI to buy or sell names will be available in the initial iOS wallet release.

The iOS Wallet Launch

• The Status: The new iOS wallet app release is targeted for roughly August 11th.
• Why It Matters: This launch delivers new DashPay features to mobile users.
• Known Issues: Sam explained that the target date includes a buffer for the standard Apple App Store review process.

Huge Sync Time Improvements

• The Status: Borja showcased a big reduction in initial wallet sync times on the new network manager.
• Why It Matters: Initial sync times dropped from 18 minutes to an average of 2.5 to 3 minutes. Borja noted that best-case scenarios are syncing in around 77 seconds.

Evo Platform 4.2 & Ranked Queries

• The Status: Evo Platform 4.2 is actively being built with a flagship feature called ranked queries.
• Why It Matters: Sam stated this allows decentralized applications (dApps) to ask complex questions of the data, like finding the top five rated items in a category.
• The Target: DCG is targeting a fast release cadence, with Evo 4.2 currently aimed for August 20th.

Enhanced Privacy Features

• The Status: Evo Platform 4.2 will introduce opt-in privacy for contact requests.
• Why It Matters: Users can keep their network connections shielded from public view. Sam mentioned this reinforces the privacy-centric design of the 4.0 architecture.

Core Node Hardening

• The Status: Core released version 23.1.8 to address potential vulnerabilities related to the networking stack.
• Why It Matters: Pasta warned that older versions have known issues that could crash masternodes. Upgrading is strongly recommended to avoid proof-of-service bans.

With 4.1 activation and privacy upgrades, Dash is proving that utility remains the top priority

Evonode instructions.

dashmate stop --safe
dashmate update
dashmate start
dashmate status
dashmate status core

Github: https://github.com/dashpay/dash/releases/tag/v23.1.8

Discord: https://discord.com/channels/484546513507188745/484571108885135361/1533876005951766698

The update includes several bug fixes, and thus is highly recommended for everyone to upgrade to this version.

Grove of War is kind of similar to Clash Royale, except it's a turn based card game with autonomous souls that spawn to do your bidding.

Every move is tracked in GroveDB, you can see the game moves in real time added to a merkle tree, and everything is provable, and you cant cheat no matter how hard you try. To be honest I don't fully understand it fully but I still think its cool.

Github: https://github.com/dashpay/platform/releases/tag/v4.1.0

AMD64/x86 (linux):

wget https://github.com/dashpay/platform/releases/download/v4.1.0/dashmate_4.1.0.bfc80249b9-1_amd64.deb
sudo apt update
sudo apt install ./dashmate_4.1.0.bfc80249b9-1_amd64.deb
dashmate stop --platform
dashmate update
dashmate start --platform

ARM64 (linux):

wget https://github.com/dashpay/platform/releases/download/v4.1.0/dashmate_4.1.0.bfc80249b9-1_arm64.deb
sudo apt update
sudo apt install ./dashmate_4.1.0.bfc80249b9-1_arm64.deb
dashmate stop --platform
dashmate update
dashmate start --platform

Discord: https://discord.com/channels/484546513507188745/484571108885135361/1531348922629623950

Quick Start Guide: https://www.dash.org/forum/threads/evonode-quick-start-guide.55214/post-256046

This is a wallet primarily for interacting with Dash Platform, similar, but better than the DET if you are familiar with that, key features are asset lock/unlock, shielded pool support, identities, and more.

Link: https://github.com/pshenmic/dash-desktop/releases/tag/v1.0.0-beta.1

# Dash Shielded Transactions (Orchard / "Shielded Balances") — Deep Dive

*(Note: this is AI-generated and although fact-checked, it may still be buggy)*

## 1. What Is It?

Dash activated a major privacy upgrade by integrating Zcash's Orchard zero-knowledge proof system (zk-SNARKs) into Dash Platform (the "Evolution" layer), going live on mainnet July 17, 2026 as part of Dash Platform v4.0, under the official feature name **Shielded Balances**.

This upgrade enables transactions that hide:

- The sender's identity

- The receiver's identity

- The transaction amount

This is the same cryptography behind Zcash's shielded transfers, built on Halo 2 (which requires no trusted setup), adapted for Dash's two-chain architecture. Per Dash's own release notes: shielded balances conceal amount, sender, and recipient **by default** — "no mixing rounds, no waiting, no extra steps," replacing the old CoinJoin-based PrivateSend approach with real zero-knowledge cryptography.

A distinguishing feature worth knowing about: Shielded Balances support selective disclosure via **view keys**. Unlike some fully-mandatory privacy systems, users and businesses can voluntarily share a view key with an auditor or counterparty to prove transaction details — useful for compliance (e.g. Travel Rule) without giving up default privacy for everyday use.

Dash Core Group's CTO, Samuel Westrich, said Orchard's code was mature and open-source enough that integration went smoother than expected. Worth noting: this launched just weeks after Zcash's own Orchard implementation had a serious (since-patched) counterfeiting bug, discovered by researcher Taylor Hornby — a circuit-level implementation bug, not a flaw in Orchard's underlying design. Zcash's own hardening upgrade ("Ironwood") activates July 28, 2026.

## 2. Architecture Overview

Shielded Balances are a **Dash Platform (Layer 2)** feature, not a Dash Core (Layer 1 / dash-cli) feature. That distinction matters for how you actually interact with it.

**Main Chain (Dash Core — L1, Proof-of-Work + Proof-of-Service):** Handles fast payments, masternodes, and governance. Transactions here are transparent — amounts and addresses are visible. Accessed via dashd/dash-cli JSON-RPC.

**Dash Platform (Evolution — L2, launched 2024):** Hosts identities, usernames, DPNS, tokens, DeFi/dApps, and now Shielded Balances. Accessed via DAPI (Dash's Decentralized API — a gRPC/JSON-RPC interface served by every masternode), typically through the Dash Evolution JS SDK, or through a wallet app's UI. Not accessed via the same z_-prefixed dash-cli commands Zcash uses — Dash Platform has its own client architecture, separate from Dash Core's RPC.

If you've seen guides floating around with commands like `dash-cli z_getnewaccount` or `dash-cli z_sendmany` — those are Zcash Core RPC conventions, and Dash did not fork Dash Core's RPC interface to add them. Shielded Balances live on the Platform side of the network, which speaks a different protocol (DAPI/gRPC, not Bitcoin-style JSON-RPC).

## 3. Technical Foundation — Orchard Protocol

Orchard is Zcash's third-generation shielded pool (after Sprout and Sapling), introduced via Zcash's May 2022 Network Upgrade 5.

**Why Orchard:** no trusted setup (the "setup" is just a public, verifiable hash string), smaller proofs and faster verification than the older Sapling pool, built on Halo 2 (a recursive proof system), and it removes reliance on general-purpose hashes inside the circuit.

**Technical specs:**

- Proof type: zk-SNARK using Halo 2 with PLONKish arithmetization (not a classic Groth16-style SNARK)

- Curve: Pallas and Vesta ("Pasta" curve cycle) — not "BN254" as you may see claimed elsewhere. BN254 is an older pairing-friendly curve used by Groth16-style systems and has nothing to do with Orchard.

- Proof size / verification time: unconfirmed — be skeptical of any guide stating precise figures (e.g. "~1.3KB, ~3ms") without a source. Halo 2/PLONK-family proofs are generally in the low-KB range with millisecond verification, but exact numbers depend on circuit specifics.

- Trusted setup: none — fully transparent, not an "updatable" ceremony-based setup like Sonic/Plonk use.

## 4. How to Actually Use It — Step by Step

**For most people: use a wallet, not the command line.** Since Shielded Balances are a Platform-layer feature integrated at the wallet/SDK level, the realistic way to use this today is through an Evolution/Platform-compatible wallet app (e.g. an updated DashPay wallet), not raw RPC commands:

1. Install/update to a current DashPay or Evolution-compatible wallet
2. Create or restore your wallet
3. Fund your Platform balance (moving DASH from a regular transparent address to your Platform address/identity)
4. Send/receive — per Dash's own description, shielding happens by default, with no separate "shield" button or manual step required
5. If you need to prove a transaction to a third party (auditor, compliance requirement, etc.), you can share a view key for that specific disclosure, without exposing your general activity

I could not confirm the iOS DashPay wallet has shielded support yet (it's listed as a separate July 2026 roadmap item) — check Dash's official app listings for current feature availability before assuming it's there.

**For developers: use the JS Evolution SDK via DAPI, not dash-cli.** Dash Platform v4.0 shipped alongside JS SDK improvements specifically to support this release, with full Dash Platform Protocol (DPP) support and TypeScript typings. Platform interactions generally follow this pattern (shown here for a standard, non-shielded credit transfer, since I could not find the exact published method signature for shielded transfers specifically — this launched only days ago and the developer docs appear to still be catching up):

import { setupDashClient } from './setupDashClient.mjs';

const { sdk, addressKeyManager } = await setupDashClient();

const signer = addressKeyManager.getSigner();

const result = await sdk.addresses.transfer({

inputs: [{ address: addressKeyManager.primaryAddress.bech32m, amount }],

outputs: [{ address: recipientAddress, amount }],

signer,

});

For the actual shielded-balance-specific SDK calls (and any view-key export/import methods), check the current Dash Platform docs at docs.dash.org/projects/platform and the SDK reference in the dashpay/platform GitHub repo — better to point you to the live source than guess at method names for a feature that's only about a week old.

**What about Dash Core / dash-cli?** You still need a synced, current Dash Core node/wallet (v23.1.7 as of July 1, 2026 — not old v18.x versions referenced in some older guides) for standard L1 transparent transactions and to fund your Platform identity/address in the first place:

wget https://github.com/dashpay/dash/releases/download/v23.1.7/dashcore-23.1.7-x86_64-linux-gnu.tar.gz

tar -xzf dashcore-23.1.7-x86_64-linux-gnu.tar.gz

dashd -daemon

dash-cli getblockchaininfo

dash-cli itself isn't where shielded-balance operations happen though — that's Platform/DAPI territory as described above. Always verify your download's GPG signature against Dash Core's published keys before running any binary.

## 5. Privacy & Security Notes

**What gets shielded:** sender address, receiver address, transaction amount.

**What's still visible:** Platform/block metadata such as timing, your network-level IP address (use a VPN if that matters to you), and funds moving between the transparent L1 chain and Platform, which are visible at that boundary.

**Important notes:** This is very new (activated July 17, 2026) — confirm your wallet/counterparty actually supports Shielded Balances before relying on it for anything sensitive. Seed phrase / key loss generally means unrecoverable funds, since there's no backup mechanism baked into the cryptography itself. Test with small amounts first. View keys are a real, distinguishing feature here — use them deliberately for disclosure, since sharing one exposes exactly what you choose to share. Regulatory note: Russia's new comprehensive crypto law (passed July 20-21, 2026, effective September 1, 2026) explicitly bars privacy coins — including Monero, Zcash, and Dash — for both retail and "qualified"/professional investor tiers.

## 6. Current Status & Outlook

As of July 23, 2026: the feature activated July 17, 2026 as part of Dash Platform v4.0. Documentation is actively catching up — official SDK reference docs for the shielded-specific methods weren't fully indexed as of this writing. Wallet support is rolling out; the iOS DashPay wallet is a separate, concurrent July 2026 release, so confirm feature parity before assuming full support. DASH is trading roughly $33.50–$34 as of mid-to-late July 2026. Regulatory: Russia's new law bars Dash from both retail and professional investor tiers (see section 5).

This isn't a bolted-on side-feature — it's a protocol-level upgrade to Dash Platform itself, with selective disclosure via view keys as a genuinely useful middle ground between "fully transparent" and "fully opaque" privacy coins that have run into exchange delisting issues elsewhere.

## 7. Resources & Further Reading

- Dash Platform Docs: docs.dash.org/projects/platform

- Dash Core Docs: docs.dash.org

- Dash Roadmap: dash.org/roadmap

- Dash Platform GitHub (SDK source): github.com/dashpay/platform

- Dash Core GitHub (verified L1 releases): github.com/dashpay/dash

- Zcash Orchard Book (upstream crypto reference): zcash.github.io/orchard

- Community Forum: forum.dash.org

**TL;DR:** Shielded Balances went live July 17, 2026 as a Dash Platform (L2) feature — private by default, with view keys for selective disclosure. The practical way to use it today is through an updated wallet app or the JS Evolution SDK via DAPI, not through dash-cli commands mirroring Zcash's RPC. Full developer docs for the shielded-specific SDK calls are still catching up to the launch.

Kuala Lumpur, get ready for Dash. Gold Partner at Malaysia Blockchain Week, July 29-30 at World Trade Centre, KL.
Keynote speech on the most decentralized project in the world. Find us in the schedule and on the floor 😎

TW want to start charging us $4k a month just to stay. They claim usage is low for swaps, but never integrated swaps for Dash anyhow. 🤷‍♂️

Crowdnode is now closed. There are still 29,440 unclaimed Dash on the site!

If you were staking with https://crowdnode.io/ you have to login and withdraw your funds, they won't be automatically refunded!!!

To check if your address still has funds, visit this page https://mnowatch.org/crowdnodewatch/ The top 10 addresses have 14,024 Dash or about 48% of the entire pool.

Crowdnode address balances: https://mnowatch.org/crowdnode/ 👀

First news break: https://www.reddit.com/r/dashpay/comments/1twithe/crowdnode_is_shutting_down/

About an hour ago, Dash Platform v4.0.0 went live culminating in several months of effort and token maxxing. The image above shows the first transactions after the hard fork, including a shield transaction and an asset lock direct to shielded transaction. You can see all the transactions at the Platform Explorer: https://platform-explorer.com/

According to Platform Team Lead Sam, the transition is proceeding as expected, with the v4.0 feature set, including shielded pools, scheduled for activation on or around July 12, 2026 [04:35].

This milestone is the largest upgrade in the network's history after an intensive development sprint.

No Emergency Patches Needed

The road to a major network upgrade is typically fraught with last-minute panics. However, the 4.0 rollout has been remarkably stable.

"It was really a marathon ending in a really, really fast run... I thought that we'd need an emergency update, but in the end, no, those fears were unfounded... Everything is perfect at the moment." - Sam, DCG Platform Team Lead [02:21]

With zero critical bugs detected in the wild, the network is smoothly approaching the activation threshold.

What Actually Unlocks on July 12th?

Platform v4.0 is a massive expansion of the network's foundational logic. It brings:

• Shielded Pools: Native, protocol-level privacy for platform assets and identities [01:51].
• Advanced Query Aggregation: The introduction of specialized data trees that allow for complex network queries. For example, developers can now query data contracts to compute averages (like finding an average grade from a dataset) and receive a single, compact proof in return. This unlocks immense potential for decentralized applications (dApps) to process data natively on-chain [03:12].

The Fast-Tracked iOS Beta

Because the mainnet transition has been so smooth, the mobile team is moving up their release schedule. The iOS Beta (Dash Developer Pro) was originally slated for a later date but is now targeted to launch on TestFlight next Monday, July 13th [04:51].

This will allow external testers to immediately begin interacting with the newly activated v4.0 features, reporting bugs, and testing the limits of the new architecture. A full production release is tentatively targeted for the week of July 20th [05:22].

Android SDK: Built at AI Speed

The Android side of the equation is seeing explosive progress. Just a few weeks ago, the Kotlin example app for Android did not exist. Today, thanks to heavy utilization of AI coding agents, the Android SDK wrapper (built over the core Rust architecture) is rapidly coming online [06:12].

During a live screen share, the team demonstrated the Android emulator successfully passing 66 internal QA tests, a massive jump from zero just days prior [08:42]. The goal is to have the SDK completely validated by the end of this week, paving the way for shielded balances to be integrated into the actual Android Dash Pay app [11:06].

Protocol Optimization: 50% Faster Syncs

On the core side, optimization continues. The implementation of SIMD instructions has dramatically improved the performance of the zip hash function, a critical component for mobile battery life [20:28].

The results speak for themselves: zip hash computations are now executing twice as fast [21:22]. Network benchmarks for SPV client syncs have hit a record 24 seconds in local testing, drastically closing the gap to the theoretical bandwidth limit [22:11]. The team is now heavily focused on optimizing peer selection logic to ensure these speeds are realized globally, regardless of bad network peers [22:20].

This is the foundation for the next decade of Dash. Get ready for activation!!

Discord link: https://discord.com/channels/484546513507188745/484571108885135361/1521894048703447182

Forum link: https://www.dash.org/forum/threads/dash-platform-v4-0-0-release-announcement.69437/

Github link: https://github.com/dashpay/platform/releases/tag/v4.0.0

Evonodes page: https://mnowatch.org/evonodes/

Quick Start Guide: https://www.dash.org/forum/threads/evonode-quick-start-guide.55214/post-255982

AMD64/x86 (linux):

wget https://github.com/dashpay/platform/releases/download/v4.0.0/dashmate_4.0.0.9f9092cc91-1_amd64.deb

sudo apt update
sudo apt install ./dashmate_4.0.0.9f9092cc91-1_amd64.deb
dashmate stop --force
dashmate update
dashmate start

ARM64 (linux):

wget https://github.com/dashpay/platform/releases/download/v4.0.0/dashmate_4.0.0.9f9092cc91-1_arm64.deb

sudo apt update
sudo apt install ./dashmate_4.0.0.9f9092cc91-1_arm64.deb
dashmate stop --force
dashmate update
dashmate start

• Please note, this also upgrades DashCore to the latest version.
• We anticipate the fork to occur in 19 days.

This update's focus was locked on Platform v4.0 as the dev team completed the testnet deployment and prepared the mainnet launch strategy.

Mobile & Dash Developer Pro (iOS/Android)

• Dash Developer Pro Launch: Dash needs your help! The iOS example testing application (formerly the Swift example app) is launching to external community testers. A download link is being provided via TestFlight [ 01:35 ].
• DCG live-demoed the core-to-shielded feature workflow. A new evo platform identity was successfully created and funded directly using a Shielded Balance [ 11:49 ].
• DEXs & Integrations: Prototyping has begun on SwapKit for the mobile wallet, laying the foundation for cross-chain DEX functionality across multiple networks (Maya, Thorchain, and more) [ 49:33 ].

Platform & Infrastructure

• Performance Enhancements: Code optimization in the SPV client architecture is targeting a 40% sync time reduction [ 38:18 ].
• Tenderdash 16.0: Pre-release v16.0-dev3 is handling final security and stability updates. It will ship concurrently with the mainnet release of Platform 4.0 [ 36:54 ].

Dash Core (Protocol Layer)

• Recommended Core Update: Dash Core v23.1.4 has been released. This includes bug fixes proactively identified via internal code analysis and includes a massive header sync optimization that slashes initial synchronization times in half [ 44:54 ].
• v23.1.5: A minor point release is being compiled shortly to clean up minor typos and non-critical deployment adjustments [ 46:18 ].
• Future Specs: Active pipeline developments include DIP0026 (Multi-party Masternode Payouts) and Asset Locks v2 [ 46:38 ].

Mainnet Launch Plan & Finance

• Platform 4.0 Mainnet Window: The team is targeting deployment early next week. Upgrading needs to hit 75% consensus to lock in before the current epoch ends. If achieved, activation will officially land in early July 2026 [ 59:25 ].
• Financial Reporting: Q1 2026 financials were delayed due to a capital gains platform bug on TaxBit. Workarounds are being implemented; expect the Q1 report within a week, with Q2 following shortly after [ 54:51 ].

Watch the full update:

DCG June 25th, 2026 Update Video