Private Money or Private Tokens? Dash, Zcash, and Ryo at the Halo 2 Crossroads

I. One Tool, Different Choices

Halo 2 is a zero-knowledge proving system, not a monetary policy. It provides machinery for demonstrating that specified rules have been followed without revealing the private information used in the proof. Zcash’s Orchard protocol uses Halo 2 to construct shielded transactions; Orchard is not another name for Halo 2. ^[6]

A naming distinction matters. Orchard also refers to Zcash’s original shielded value pool. Ironwood, activated on July 28, 2026 through NU6.3, is a newer, separate Zcash value pool using the Orchard protocol and the same Halo 2 proving system. Ironwood is therefore not a new proving system; it is a successor pool with its own state and additional safeguards. ^{[17, 18]}

A project must still decide which information stays private, whether transparent transactions remain available, and whether its rules support only the native currency or additional assets. Sharing a cryptographic foundation does not settle those choices.

Two decisions are especially important here. Privacy policy determines whether confidentiality is required or optional. Asset policy determines whether the network supports one monetary instrument or many. Mandatory privacy does not logically prohibit asset issuance, just as optional privacy does not require it.

There is also no clean division between “Ryo money” and “Dash or Zcash tokens.” DASH and ZEC are native cryptocurrencies too. Adding a separate token does not turn the native coin itself into a fiat-backed claim. The question is what extra responsibilities a network accepts alongside its native money. ^{[7, 8, 4]}

II. Dash: A Wider Private Economy

On October 20, Dash announced Platform 5.0. The release has been live on testnet since October 15, with the mainnet software release scheduled for October 26. Protocol version 14 is targeted for activation on November 8 if enough EvoNodes signal readiness for lock-in on October 30. Releasing the software alone does not activate the new rules. ^[1]

This follows the existing launch of Orchard-based shielded transfers on Dash Evolution, announced in August. Dash uses Orchard technology inside its own Platform; its shielded Dash credits and token pools are not Zcash’s Orchard or Ironwood pools. The new step is extending confidentiality to issued tokens, rather than introducing private Dash Platform transfers for the first time. ^{[1, 7]}

The shielded-token model gives each enabled token its own private pool. Tokens can enter from visible balances or be issued directly into the pool; supported private transfers can pay fees from shielded Dash credits. The feature broadens what an application can transfer confidentially. ^[9]

There are boundaries. Tokens with these pools must permanently disable individual freezing and confiscation, but token-wide pausing remains possible. Separate pools also mean that a lightly used token does not automatically share the privacy benefits of activity in other token pools. ^[9]

For a business or community, this could make a rewards balance, internal payment instrument or other token more useful. A stablecoin is one possible application, not the definition of the feature.

Infrastructure is not issuance. Enabling a shielded token does not, by itself, establish a regulated issuer, reliable reserves, redemption access or market liquidity. A private dollar would still need an arrangement that makes it a dollar claim. Dash has expanded the design space; it has not abolished the work outside the ledger.

III. Zcash: Not Now Is Not Never

Zcash Shielded Assets, or ZSAs, approach the expansion through the proposed OrchardZSA protocol. ZIPs 226 and 227 describe custom-asset transfers, burns and issuance. The design seeks multi-asset shielded activity, including concealment of the asset type in protected transfers, rather than treating each asset as an entirely separate privacy population. ^{[2, 8]}

The live Zcash shielded-payment environment has also changed. After the discovery and correction of an Orchard proof-soundness vulnerability (a potential counterfeiting risk), NU6.3 activated the Ironwood pool on July 28, 2026 to strengthen confidence in supply integrity. Ironwood is distinct from the original Orchard pool, which is now restricted, but both use the Orchard protocol and Halo 2. Ironwood does not itself introduce additional assets. ^{[17, 18]}

That distinction matters for ZSAs. QEDIT’s October 6 update reports that OrchardZSA is being adapted to NU6.3, alongside continuing software integration and experimental testnet work. The proposed extension is not a feature already available inside Ironwood. ^{[10, 18]}

NU7’s current draft specification introduces no new transaction format and does not include ZSAs. But postponement is not abandonment: QEDIT’s continuing engineering work provides evidence of ongoing development, without a confirmed mainnet activation for shielded assets. ^{[3, 10]}

The disagreement is also older than Dash’s latest announcement. In January, forum participant maxdesalle argued against ZSAs on grounds including security complexity, issuer influence and development opportunity cost. A responding thread by artkor defended broader private-asset uses and the possibility of new economic activity. These are competing community positions, not binding decisions for the whole network. ^{[11, 12]}

Both sides identify a real strategic question. Greater functionality can attract users who would not otherwise use ZEC. It can also demand engineering and ecosystem support that might have improved the native currency instead. Neither effect can be established merely by counting the assets a protocol could issue.

Zcash is therefore not a convenient example of a project that has rejected tokens. It is an example of the harder process: deciding which extension belongs in a monetary network, and when it is ready to become part of that network’s obligations.

IV. Optional and Mandatory Privacy

The word optional requires care. Zcash permits transparent and shielded transactions at the protocol level. That does not mean a properly constructed shielded payment is only partially protected because other users transact transparently. Nor does it prevent a wallet from making private payments its normal experience. ^[13]

What changes is whether a transparent path remains valid at the protocol layer. A wallet can make shielding convenient, but it cannot change which transactions consensus accepts. Ryo already requires privacy for ordinary native transfers under RingCT, and its Halo 2 transition is designed to preserve that mandatory-private approach rather than introduce a transparent opt-out. ^[4]

That baseline is meaningful: privacy is part of an ordinary RYO transaction, not a setting the sender must remember to enable. It does not, on its own, settle every anonymity question. The number of users, their transaction patterns, public entry and exit points, and the software around their funds remain important.

Dash’s documentation makes the narrower pool problem explicit: confidentiality depends in part on other activity in that particular token’s pool. A cryptographic note is not a verified independent person. Counting notes is therefore not the same as counting unrelated users. ^[9]

A comparison based only on the labels “Halo 2” and “default” would therefore miss the real design choices. What matters is which transactions are permitted, what information remains visible, and how privacy behaves as the network is actually used.

V. Ryo: Halo 2 Moves Toward Deployment

Ryo’s development team has supplied a much more concrete progress update than a general roadmap promise. The core implementation work, the team says, is largely complete. Attention has shifted to testing and coordinating the upgrade’s deployment:

“The core coding work is largely complete. Focus is now on testing and deployment coordination. Stay tuned. 😉”

— Ryo Currency team, Telegram development update, October 3rd, 2026. ^[5]

That is a meaningful change of phase. Ryo is no longer chiefly describing the privacy architecture it hopes to build; its developers report that the central coding work has largely been done. The practical questions now concern how the implementation performs under testing, how wallets and nodes make the transition, and when activation can be coordinated.

This work is not a minor formality. A privacy upgrade must demonstrate both confidentiality and the ability to reject invalid transactions under real network conditions. But it is the work of preparing an implemented system for release, not of deciding whether to begin building it. The team has not announced an activation date.

Ryo’s current mainnet continues to use mandatory RingCT privacy. Its coming Halo 2 transition is intended to replace that mechanism while preserving privacy as a requirement of ordinary native RYO transactions. Using a Halo 2-based approach does not mean Ryo is adopting the Orchard or Ironwood pools: those are Zcash protocol structures, while Ryo operates an independent blockchain. The team-reported move into testing and deployment coordination places Ryo’s next milestone on the path toward its own mainnet activation. ^{[4, 5, 6, 18]}

The timing sharpens the shielded-asset question. With most of the core native-privacy work reportedly complete, should Ryo complicate the rollout by adding token functionality, or bring the planned upgrade through testing and activation first? The latter is a sequencing recommendation, not a claim that other assets could never belong on Ryo.

VI. A Private Dollar Is Still a Dollar

Consider a merchant who owes a supplier $10,000 next month. A confidential dollar-denominated instrument could reduce public exposure of the payment without asking the merchant to take a month of native-coin exchange-rate risk. That is a legitimate problem to solve.

Dismissing such users as having no need for privacy would confuse a monetary preference with a practical obligation. People can value confidentiality while keeping their accounts in an existing currency.

But the shield changes visibility, not the underlying promise. For an issuer-backed dollar token, someone must still maintain the backing and honour the relevant redemption arrangements. The holder has not escaped those dependencies merely because outsiders cannot follow every transfer.

Circle’s USDC terms provide a concrete example of this separate control layer: redemption and use are subject to conditions, and the issuer describes blocking and freezing powers. This is evidence about USDC’s issuer relationship, not a claim that USDC has launched as a DSA or ZSA, or that either protocol gives its issuers identical powers. ^[14]

The same care is necessary in the opposite direction. Disabling a particular on-chain control does not compel an outside institution to redeem a claim. Conversely, an issuer’s ability to refuse redemption does not prove it can identify and individually freeze every shielded note. Ledger controls and off-chain obligations must be examined separately.

Making a dollar transfer private does not make the dollar independent.

This criticism concerns issuer-backed claims, not every possible stable-value design or custom asset. Nor is independence a promise of stable purchasing power. Native cryptocurrencies still depend on functioning software, network participation and willing counterparties. Their narrower distinction is that ownership does not require an issuer to redeem each coin for something outside the network.

The two objectives can therefore coexist: make existing financial instruments less observable, and build money that is not an external redemption claim. A privacy project need not treat the first objective as worthless to decide that the second deserves its full attention.

VII. The Strongest Case for Shielded Assets on Ryo

The strongest case for a hypothetical Ryo shielded-asset system is not that Dash and Zcash have explored the idea. It is that some people need confidential payments in assets other than RYO.

A supplier may demand a particular settlement unit. A community may want a transferable instrument with rules different from the native currency. An application may require an asset representing a distinct entitlement. ZSA proponents explicitly envisage uses beyond stablecoins, including custom and externally represented assets. ^[15]

Such functionality could bring additional users, developers and transaction activity to an existing privacy network. Merchants might integrate with one wallet infrastructure for native RYO and other private instruments, while fee-paying activity could support demand for the native coin. These would be potential benefits, not demonstrated outcomes for an RSA system that has not been proposed by Ryo.

Crucially, supporting other assets would not automatically make native RYO transactions optional or transparent. Privacy defaults and asset policy are separate design choices. If a sound multi-asset system could preserve Ryo’s native privacy rules, an expansion might strengthen its payment ecosystem without abandoning that principle. The challenge is to establish that the additional complexity produces a benefit users actually need.

The case deserves to be taken seriously. Requiring every prospective user to adopt RYO as both a payment instrument and their preferred unit of account would narrow the group the network can serve. A broader system might meet people where their obligations already are.

Still, capability is not demand. “Someone could issue a token” is a weaker case than identifying who would use it, why it must operate natively on Ryo, and who would maintain the necessary wallets, liquidity, issuance and redemption systems. The strongest proposal would begin with those answers, not with an acronym.

VIII. Protecting the Deployment Window

The best argument for deferring native shielded assets is no longer that Ryo has an uncertain privacy project to begin. It is that the core Halo 2 work is reportedly largely complete and a specific deployment effort now deserves priority. An otherwise useful addition could still be badly timed.

A larger job than private transfers alone

An asset system needs rules for creating and distinguishing instruments, preserving their balances, and handling their lifecycle. Wallets must explain what a user holds, who or what stands behind it, and which rules apply. The need for separate issuance and transfer specifications in OrchardZSA illustrates that this is an additional protocol responsibility, not merely a new label in a wallet. ^{[2, 8]}

This does not tell us how difficult a future asset feature would be for Ryo. The present analysis does not inspect the Halo 2 implementation or estimate RSA development costs. It asks the more immediate question: would new asset rules create fresh wallet, testing or consensus obligations during a coordinated privacy upgrade?

Activity is not automatically native-money adoption

Suppose a private dollar token became the most used instrument. The network might gain transaction demand while users held the native coin mainly to pay fees. Depending on fees, usage and user behaviour, that could support the native asset or leave it with a narrower monetary role. Neither result follows automatically from higher token activity.

A project seeking wider use of independent money should therefore measure more than transaction counts. It should ask what users hold, what they price goods in, and which asset they rely on when making payments. This is an economic-design question, not a price prediction.

Protect the next milestone

Ryo’s broader vision includes network-layer privacy and a future private-staking architecture, but these are separate development objectives. The team’s latest update is specifically about its Halo 2 coding and move into testing and deployment; it does not imply the entire roadmap is complete. ^{[16, 5]}

The priority, in this report’s assessment, is straightforward: test and activate the largely implemented native privacy upgrade before considering another major consensus feature. That protects the project’s near-term delivery objective while leaving room to assess asset issuance on its merits afterward.

IX. When Would Shielded Assets Earn a Place?

Prioritizing the Halo 2 rollout does not require a permanent prohibition on other assets. It gives Ryo a clear order of operations: deliver its native-privacy upgrade, then judge any proposal for additional assets against concrete criteria.

First, demonstrate the need. Identify a real use case that native RYO does not adequately serve. Explain why a separate system or integration would be insufficient, while acknowledging the extra trust such alternatives may introduce.

Second, account for the cost. Specify the privacy, security, wallet and maintenance implications. Show how any issuer or asset-specific control would be kept distinct from ordinary native RYO, and who would support the feature over time.

Third, justify the timing. Explain why the expected benefit outweighs the work displaced. The case should remain persuasive without claims of inevitable adoption, guaranteed fee demand or automatic improvement in RYO’s value.

A non-fiat application could pass that test. A stablecoin application could also deserve examination. But “the technology allows it” is not enough. The standard should be whether the feature makes the network better at a task its users actually need.

Conclusion: What Is the Network For?

Dash’s planned token expansion shows how Orchard-based privacy can support additional instruments. Zcash’s live Ironwood pool and still-developing ZSAs represent two different tasks: protecting native shielded payments and extending those protections to custom assets. Ryo’s team reports that its core Halo 2 coding is largely complete, with testing and deployment coordination now the focus. ^{[1, 17, 10, 5]}

The comparison does not establish that private tokens are a mistake or that one native currency is automatically superior. It establishes that privacy networks can pursue different objectives with related tools.

For Ryo, the immediate question is increasingly when its mandatory Halo 2 architecture can reach mainnet, not when its developers might start building it. The sensible sequence is to bring that upgrade through testing and deployment, then require any proposed shielded-asset expansion to justify its value. That is an editorial assessment of focus, not an announced decision by the Ryo team.

The measure of progress is not how many assets a blockchain can hide. It is whether the privacy it delivers serves the purpose its users need.