If you have read Part 1 - Combining ZK and Data Contracts, then there should be one question on your mind.
It is NOT.. How do we do messages, payments with data, or payment requests? (Which will be discussed below also)
It should be:
Why not just pass the ReferenceID through the ZK memo field? And not bother with the DocumentID at all..
Defending the Design Choices
“Advantage #2 is my favorite.” - TL
2 Document Types vs 3 Document Types
The Contact “Anchor” or “Root” Document - Design Choice
Advantage #1 - Decouple the encryption of ZK transaction from the encryption of the Platform document.
This one is interesting because changing the encryption of ZK is a big deal as it would affect the entire protocol, so separating the document encryption from the ZK makes it easier to upgrade the encryption of the Platform document in the future as it is implemented by the dapp (or at the client level) when the document is created.
Therefore, the DocumentID is passed using the ZK memo encryption, and the ReferenceID (and other data as desired) is passed by AES-256 using the ECDH shared secret of identity keys, all stored in the “Data” property field of the Contact Anchor Document.
Advantage #2 - Remove ZK TX reliance (Pruning of ZK no longer affects contacts data retrieval)
This one I found to be the most convincing. If you were to go with the 2-Document Design then you become fully reliant on the ZK transactions and the history to establish each P2P channel/tunnel.
But in the future if there is a pruning of the ZK data to improve syncing and storage costs and there is NOT a Contact Anchor document, then you could lose the data necessary to rebuild the 2-way connections. This causes each connection that is pruned to be lost.
The Contact “Anchor” document becomes the sole source necessary for all contact establishment after the initial 2-way connection is complete.
Advantage #3 - Search and restore are not linked to ZK transactions and rely only on Platform documents.
This is a bit derivative, but to make it clear. Having a Contact Anchor Document which contains both the Sender’s ReferenceID, the Recipient’s ReferenceID, and Recipient’s IdentityID (and any other data like a payment key or address), allows any wallet or dapp to restore all contacts and data without needing any ZK transactions.
So now that I have hopefully convinced you to go with the 3-Document Type Design, we can go into some more specific implementation details.
OrchardPay Data Contract Details
Shielded Address Document Type (1/3)
This document and associated ZK address are retrieved by the dapp to send the ZK transaction and pass the sender’s Contact Anchor DocumentID to the recipient.
The ownerID of the Shielded Address Document Type should be an indexed property, so when a user’s name is queried by someone that wants to form a connection, the DPNS name document will have an ownerID, and that ownerID can be used to query the Shielded Address Document.
Contact Anchor Document Type (2/3)
This is the document whose documentID is passed through the ZK memo field.
The “Data” property could also pass a Public Key for payments or an initial message for the recipient. (See extra details in the diagram above)
The “AnchorData” is encrypted with AES-256 using a private key derived from an HD path from the wallet. (This should probably be specified in a DIP. This is so it is easy to find for any dapp.)
The “AnchorData” needs to contain both ReferenceIDs from the sender and the recipient. This means that the first sender will probably need to update this property to add the recipient’s ReferenceID once the recipient sends back to the sender (forming the 2-way connection). This property can also store a payment key or address that is passed as well.
Encrypted Message/Data Document Type (3/3)
The ReferenceID is a Platform Identifier or “32 random bytes”. The RefID is an index of this document type and is used by all the documents that one user wants to send to another.
This document type is what is used for all the messages, requests, info, etc. (See more below)
Should also be deletable and mutable, so has the createdAt and updatedAt properties.
An implementation!
This part is all about using the Encrypted Msg/Data (3/3) Document Type, so this is how a dapp works.
One of the important implications of having fully encrypted documents to pass data to and from users means that attributes of documents are no longer enforced at the protocol level. **
This feature is just like an “anonymity set”, but it’s an “anonymity of usecases set” so not only does no one know what is being sent, nor who it is being sent to, it is also unknown what purpose is behind a document: sending a message, a request, a payment memo, purchase order or group invite, because they all look the same.
The Power of OrchardPay = Feature Extensibility!
These 3 data documents are examples of OrchardPay features/usecases that are sent from Alice to Bob like in Part 1. They all use the same RefID. The RefID is what is passed from Alice to Bob like the Diagram 4 of Part 1 shows.
Since only Bob knows the ReferenceID, and because the encryption is a shared secret of Alice and Bob. The data and who is involved is completely private.
In closing
What makes OrchardPay terrifying is not how awesome Dash Platform is (which it is) nor how powerful ZK is (which it is), but how simple and easy they are to combine.
AI will be able to build so many things using this tech, and so many people will be using these dapps.
Combining ZK and Data Contracts is the killer app!
And it is called OrchardPay.
(Added 13 May 2026)
I have not included an exact prescription for how to do payments through the shielded address. This was intentional as there are many ways to accomplish this and there are many ways to do payments with Dash. There is core transactions, platform addresses, shielded transactions, credit transfers, etc..
But there is one way that I wanted to share, as it was alluded to in the first article.
“Using 2 SHIELDED addresses: a public address and a private address”
The public address is the address in the “shielded address document”. This address is specifically used to establish OrchardPay contacts, but it could be used to make an initial payment also while establishing the 2-way connection.
The private address is the new idea here. The private shielded address is passed through the “contact anchor document” and allows for the payment requests and payment memos to put a documentId of the “Encrypted Msg/Data documents” in the zk memo field. This forms a powerful 2 way linkage between data and payments.
This is interesting as only your OrchardPay contacts will know about this address, so it opens up a more flexible way to use a shielded address between contacts.