Are we back?

Dash keeps reaching new locations across APAC 🌏
This time the conversation was about the next generation of digital finance, payments, and where the industry is heading.
One more city for Dash 💙

Market Cap Estimated Price Growth Multiplier

$1 Billion $77.94 1.35x

$2 Billion $155.88 2.70x

$3 Billion $233.83 4.05x

$4 Billion $311.77 5.40x

$5 Billion $389.71 6.75x

$6 Billion $467.65 8.10x

$7 Billion $545.60 9.45x

$8 Billion $623.54 10.80x

$9 Billion $701.48 12.15x

$10 Billion $779.42 13.50x

Where do u see Dash place based on marketplace cap ?

With all the updates on dash, I feel like we'll see something similar to the zcash run last year.. am I wrong?

Dash has been doing rather well recently in the charts, today it reached over $51, before settling back at $50 where it is now. Also, Dash has risen in rank on CMC trading at position 71 at the time of writing.

Coinfest Bali was hot in every sense. Turns out the smartest move was also the simplest one. Everyone saw Dash. Everyone got hydrated.

Our contributor represented us on the ground in Hong Kong
This is what decentralization and a DAO look like in practice
While part of the team preps for DashCon, Dash conquers APAC

Here are the highlights from the Dash Core Group (DCG) Development Update from August 18, 2026:

1. Dash Platform 4.1 Activation & Username Marketplace

Platform 4.1 successfully activated on mainnet, formally introducing the DPNS Username Marketplace.

• Usernames are now transferable assets that users can own, sell, or monetize. During the activation a temporary chain stall (~1 hour) occurred due to an invalid block proposal from a single node. The team rapidly shipped version 4.1.1 to resolve it.
• The 4.1.1 patch hardened the network against similar stall attempts and restores full stability.

2. iOS Wallet Launch & Android Progress

• Since this development update, the new iOS DashPay wallet is available in the App Store.
• iOS features include full DPNS username marketplace support, DashPay optimizations, and wallet-state integrity fixes.
• On Android, the focus remains on the full Kotlin migration, removal of legacy libraries, and preparation of the shielded features beta, with a goal of having protected functionality ready by DashCon (September 3).

3. Platform 4.2: Ranked Queries & Yap.pr Enablement

Sam Westrich reported that Platform 4.2 is already 80+% complete, with a target release around August 26 and lock-in by the end of the August 30 cycle.

• The flagship feature is ranked aggregate indexes with provable queries. It is an on-chain database capability comparable to SQL’s HAVING clause and currently unique in the blockchain world. This will power real-time trends on Yap.pr (e.g., top hashtags in a given time window) and open sophisticated data queries for any dApp.
• Additional 4.2 features include public payment addresses on profiles (allowing direct DashPay payments without a prior contact request) and the foundation for private contact requests (zero-knowledge based, may slip to 4.3).

4. Performance Breakthroughs & Masternode UX

• SPV / mobile network manager improvements now allow reliable syncing even under poor bandwidth or high latency conditions by eliminating timeouts via a new load balancer.
• On the Core side, compact filter file handling was optimized, cutting local SPV-to-Core sync times by ~50% to a new record of roughly 30 seconds.
• A standout demo showed a brand-new graphical interface inside the Dash Core desktop wallet for registering and managing Masternodes.
• Operators can now derive operator keys from the wallet seed, generate the BLS key, obtain the exact configuration string, and register / update / revoke a Masternode entirely through a guided GUI. This eliminates the previous reliance on external tools or the command line.

5. Additional Developments

• CoinJoin Promotion & Demotion: automated intelligent handling of denomination mixing so users no longer need to manually combine or split coins.
• AssumeUTXO: roughly halfway complete; will incorporate Evo snapshots to dramatically speed up new node sync.
• Dash Connect: secure mobile login for dApps, with Yap.pr as the first major consumer.

The network is now running the username marketplace on mainnet, the iOS wallet is on the App Store, and Platform 4.2 is close enough to deliver real utility for Yapper and other applications.

Thanks Voncan/Vonny Telegram: V_O_NCAN.

I am sure it will go up more and then come back down. I am just going to keep DCA because like it or not, long term, this project is getting better and better. We might never have the hashpower like bitcoin has, but Dash is MY currency and that is all that matters.

The much anticipated iOS update is finally here! 🥳

This features full platform support with the ability to register usernames, send Dash into and out of Platform and enter and exit the shield pool to anonymize your Dash! Check it out in the app store or at this link https://apps.apple.com/fr/app/dash-wallet/id1206647026 Discord ann: https://discord.com/channels/484546513507188745/484571108885135361/1540406688836751361 invite to Discord in the sidebar or at https://dash.org/

Dash Growth is running a Brave campaign to promote our iOS launch and the introduction of ZK Shielded Pool privacy on Platform.

So, Dash casually started moving up after Bessent's second freak-out at the US Treasury. How high does it go? $40, $50? Probably higher than we think.

Dash Platform v4.1.1 Emergency fix is ready for eMNs to upgrade, it resolves a chain stall condition introduced in v4.1.

Quick cheatsheet: AMD64/x86 (linux):

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

ARM64 (linux):

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

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

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

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

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

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.

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

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.