This article is for the Dash Community and future builders on Dash Platform.
I write this article, because there are maybe a hundred people that know Dash Platform exists, and of those fewer than a dozen understand what it is.
Major changes to Dash Platform recently (Medusa upgrade) have made these possibilities a reality. Unfortunately, I see little movement or discussion pertaining to these ideas.
I think it is because people just don’t know.
A New Way of Building with Dash Platform
OrchardPay (because zkPay and MedusaPay were already taken) uses a combination of ZK addresses and transactions, and Platform’s Data Contracts and Documents to power a full feature P2P payment solution.
“Payment solution” in this context is NOT a credit card reader or Apple Pay, but sending money P2P like Venmo. BUT this is CRYPTO so obviously, it is completely decentralized.
But before we can get to OrchardPay, we must first look at DashPay, so we understand where we are at currently, and then the advantages of OrchardPay can be seen more clearly.
If you need to learn about Dash Platform, Identities, Data Contracts, etc, go here.
TAKEAWAYS
Achieves original goal of sending payments privately between users.
DOWNSIDES
Leaves a permanent, public social graph
No feature extensibility
Requires both sides to complete requests (handshake) prior to sending payments
TAKEAWAYS
Connections/contacts are NOT public & more than just payments is possible!
Additional possibilities include payments with descriptions, messages, payment requests, group invites, placing orders, receipts!
Both parties don’t have to complete the handshake prior to a single party sending payment or message, so sending directly is possible as well!
KEY DIFFERENCES
DashPay gives an encrypted public key for payments.
OrchardPay gives a private document reference (or starting point for more document/messages to be exchanged), so that in the future
more documents can be exchanged between the 2 users without
performing the connection again.
OrchardPay establishes a direct E2EE (End to End Encrypted) channel/tunnel
between users, so they can do payments but also data like messages,
requests, and whatever they can think of. (OrchardPay = Feature Extensibility!)
Also works directly, so don’t have to wait for both sides to complete the
initial handshake. (Once a user has a Dash Name and a public ZK address document, anyone can send to them.)
But the question remains..
If there are no public connections, then how do users connect?
=> the ZK memo field!!
How to connect with OrchardPay
The ReferenceID is added to future documents by Alice as an index. And because only Bob knows about the ReferenceID, only he knows who the documents are for and only he can decrypt them.
This diagram 4 presents one side of a connection. For it to be a complete two sided connection, Bob needs to send to Alice exactly as shown above.
Not Losing Sight of the End Goal!
Before we end this article, I want to bring back what the goal of all this is.
This article only covers the advantages and the critical mechanism behind OrchardPay. My next article will have a more complete and detailed implementation of an OrchardPay dapp. I think using a public ZK address and a private ZK address for contacts. That article will go deeper into how messages and requests and payment details are exchanged back and forth.
OrchardPay is all through the SDK and in terms of sophistication, it is not any more difficult than Yap.pr (probably less) and pastapastapasta built most of that in a month with AI.
We just need to get the right ideas to the right people.
OrchardPay eliminates the public data of DashPay, but more importantly it powers much more useful features for P2P Digital Cash!
This is what Dash Platform was build for!
The Evolution continues!
(Added 10 APR 2026)
DashPay and OrchardPay differences:
OrchardPay uses the zk memo field to pass info instead of using a public index on platform like DashPay.
OrchardPay passes a document referenceID instead of an extended pubkey. The document referenceID can be reused by multiple documents for feature extensibility while maintaining complete privacy.
OrchardPay will be the "bridge" Data Contract that is used by all future Data Contracts on Dash Platform for anything P2P.
Massive Feature Extensibility is a result as OrchardPay gives a ReferenceID for as many documents as you want to be sent between two users completely privately, instead of an encrypted public key.
The Features: Messages, Payment Requests, Payment memos, placeing orders, reciepts, etc (whatever P2P thing you can think of or whatever P2P dapp developers want to build, developers are meant to leverage the private channel established by OrchardPay to do build whatever P2P dapp they want.)
-AI- What this piece gets right is that it stops treating a data contract as a glorified profile schema and starts treating it as a coordination substrate. That is the interesting move. The OrchardPay idea is not merely “DashPay, but with more privacy adjectives”; it is an attempt to use Platform documents as a rendezvous and messaging layer around shielded payment flows, so the contract becomes an extensible interpersonal protocol surface rather than a narrow contact-exchange mechanism. -AI-
-AI- OrchardPay connection = a hidden shared reference plus encrypted documents, so two users get a private reusable channel instead of just a one-purpose payment handshake. -AI-
-AI- DashPay says “query public docs addressed to Bob”; OrchardPay says “privately give Bob a secret reference through a shielded memo, then use that secret reference for future coordination.” -AI-