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.

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:

1. OrchardPay uses the zk memo field to pass info instead of using a public index on platform like DashPay.

2. 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.

3. OrchardPay will be the "bridge" Data Contract that is used by all future Data Contracts on Dash Platform for anything P2P.

4. 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.)

5. -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-

6. -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-

7. -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-

To understand the Baptists and Bootleggers reference, we will briefly revisit the past.

During Prohibition (1920s to early 1930s) in the United States, there were strange bedfellows in the cause to end alcohol consumption.

Baptists were against alcohol on principle.

Bootleggers understood people would continue to drink alcohol whether the law said they could or not. So too the bootleggers would continue to sell alcohol whether the law said they could or not. Bootleggers were on the side of the prohibitionists as a way to increase their profits.

So both Baptists and Bootleggers wanted to make alcohol illegal, does that mean they were on the same side?

What do Bootleggers have to do with Dash?

Many people in Dash are deceived into a certain line of thinking that lines up very nicely with our Baptists and Bootleggers analogy.

Let’s first establish the dynamic between the two parties. The baptists are relatively poor, salt of the earth people, and they are many. The bootleggers are few, but they have the means to capitalize on an opportunity. Together, they form a powerful force.

For the Dash bootleggers analogy, instead of the “prohibition of alcohol” as the main driving force for the strange bedfellows, the main driving force is the narrative of Dash “usage”.

Let’s look at a common Dash narrative and see how these Dash bootleggers deceive others, just as the bootleggers of the prohibition era did.

Dash Bootleggers: Main Narrative

The Dash bootleggers just like the prohibition bootleggers, they hide their actual intentions, but we can identify them easily if we just take their words and apply some simple logic to them.

They like to espouse that “If we can get people to “use” Dash by selling Dash through 3rd party intermediaries, then we are making Dash more valuable.”

And the main crux of the argument is this:

If we can get people to “use” Dash (sell to 3rd party intermediaries), people will hold Dash in the mobile wallet, and thereby make Dash more scarce and drive the price up.

Now let us apply some logic and see through their deception.

We can see their idea falls apart when we simply walk through an actual user’s perspective.

If someone were to hold Dash in their mobile wallet, then as long as they did not use it, the bootlegger’s argument holds, and they increase scarcity and drive up price.

But actual people do not just hold things for no reason, unless it’s held as an investment (speculate that the value will increase).

Now as many people know Dash has a tier of masternodes (MNs), that earn Dash by operating nodes for the network with a certain amount of collateral locked up.

So if people were to follow the idea of holding Dash as an investment, then asking people to use Dash for gift cards is not what someone would tell them to do. In fact, what you would tell them to do is put their Dash in a MN and in cold storage, both of which are far from access to gift cards (i.e. “usage”).

But remember this is the narrative of the Dash bootlegger, and they want people to hold Dash, but not to share in the masternode rewards, because that would cut into their own profits.

The Dash bootleggers seek to extract as much value as they can, without creating any value, just like the prohibition bootleggers, they seek to maximize their own profits. I do not fault them from looking after their own, but I want to share the truth with you (the reader). So you can know and not fall into their trap.

Conclusion

If you want to know more and how to avoid these bootlegging MNOs, please read this article on the “the Culling Strategy”.

And if you want a quick way to identify them, just see if they are for P2P Digital Cash or using gift cards. If they say both, you can be sure it’s a wolf in sheep’s clothing.
P2P Digital Cash is the one and only sure way to use Dash and have all benefit.

Please don’t blame all MNOs or Dash community members, because just like during Prohibition, people thought everyone was doing it for the right reasons. In the end, Prohibition was ended and the bootleggers made a lot of profit as they had intended.

Most people were caught up in the narrative and didn’t understand the underlying intentions of all the participants. Beware of wolves in sheep’s clothing.

Just as the Dash bootleggers can pursue their profits if they want to, so too can I share the truth of their deceptions to those who will hear.

Many years have gone. But Dash is still trying to straddle 2 paths.

Who even remembers what Evan spoke about?

Evan spoke about making a better cryptocurrency. He knew privacy had to be built-in and inseparable for it to really work (Fungibility). He built PrivateSend.

He knew that there had to be a better way for the people of Dash to come together, make decisions, and fund them. He built the DAO.

And he left us with a vision for Dash Evolution.

But even more, I think Evan really believed in Satoshi’s dream of a peer-to-peer electronic money as we all do. He knew that Bitcoin wasn’t following the right path.

Evan’s Digital Cash was a pure ideal to fulfill what Satoshi set out to do. But then Evan left…

What we got in the meantime with Ryan Taylor’s strategy was a multitude of ideas for this “digital payments” to fit into the current monetary system. If we could make it as easy as possible to convert from Dash to fiat and fiat to Dash, then that would be just what we needed.

Ryan Taylor had a lot of ideas that many, including myself, thought would be best for Dash at the time. We didn’t have Evan to point the way anymore.

I do think Ryan did everything, within the bounds he found himself in, to stay true to Evan’s vision. His team let him down, and he was finding himself trapped in an ever changing crypto-regulatory landscape.

Simplify, Simplify, Simplify

I am going to make tropes of Evan and Ryan, because I don’t want this article to be too long.

• Evan’s focus was the network (DAO and masternodes) and user’s experiencing true digital cash (privacy, speed, ease of use)

• Ryan’s focus was fitting crypto into the current monetary system, ease of transferring into and out of Dash to fiat. Identify with “payments”, whatever its meaning.

The author of this article holds that they don’t fit together, and Dash can choose a different path for the future.

How does Dash choose a path?

Choosing a path is easy. Just choose what you will focus on and let everything else fall away.

I don’t have all the answers for this as it is up to the people of Dash to decide, but I will list a few.

1. Dash Pay (mobile wallets) should focus on making its product easy for P2P use, don’t focus on “being the best way to convert Dash to a gift card.”

   1. Add Private Messaging for Friends

   2. Be able to make Payment Requests with contacts

   3. Be able to make scheduled payments or payment reminders

   4. Be able to send/refer a contact to another

   5. Be able to form a multisig with contacts

2. Build things on Dash Platform

   1. The Dash Merchant Map should be merchants that accept Dash! Not where you can sell Dash and convert to a gift card. And it should run on Dash Platform.

   2. Dash Central should be moved to Dash Platform.

   3. Dash Evo Tool (DET) or something like it should be easier for users to access, it should not have a weird Dash Core connection. (Make it SPV or build something else entirely that is easier for people to use)

Can Dash return to Evan’s Digital Cash?

Evan’s vision ended at Dash Evolution, but Dash Platform pushes far beyond those bounds.

The direct answer to that question is “No.” I wrote this article, because of 2 things.

1. Dash Platform has incredible possibilities, but we lack the “how do we get all this great tech into the user’s hands?” That was always Evan’s signature touch.

2. The other was Dash Platform grows Evan’s Evolution far beyond its original bounds, but staying shackled to the “we must fit into the fiat payments/gift card space” is completely unnecessary.

If anyone wants to purchase a gift card with Dash, then by all means sell Dash and get a gift card. But buying a gift card doesn’t make something Digital Cash, you can buy gift cards with credit cards. Being like a credit card was never Evan’s Digital Cash.

(Post article responses, I thought were worth sharing for perspective)

What is Digital Cash?

Evan is gone. We have an incredible team at DCG currently, and Dash Platform is set up for some incredible possibilities currently and on the roadmap.

I know there will be many MNOs who really like the features that make it easy to spend your rewards, but MNOs spending Dash should NOT be the focus of Dash use.

If Dash is not build on and made for the average person to benefit from simply using Dash as P2P Digital Cash, then we are not on the right path. (This is what I believe.) I extend true P2P Digital Cash to using Dash directly on Dash Platform for its many use-cases as well.

In most cryptos, you will see the holders pursue a strategy of enticing buyers to purchase in order to increase said crypto’s value and thereby increase gains for the holders.

But there is another strategy that very few cryptos pursue, because the resolve needed for it, falls beyond the pale of even the most hardened holders.

The Culling Strategy

Most cryptos promise utility or opportunities for growth or community to pull in buyers and grow the market cap. But what happens when that doesn’t work any more?

Where can you get growth when there isn’t any growth left. Well in the market, there are buyers AND there are sellers. So what if, instead of trying to get more buyers (when there are no more buyers), what if you just get rid of the sellers?

Other cryptos have tried to rid themselves of sellers through crude mechanisms like lock-in periods or token conversion schemes or supply freezing, but these are pathetic attempts.

The real way to get rid of sellers is to entice all sellers to sell. This is the secret of the Culling Strategy.

But how do you do that?

How do you entice all sellers to sell, so there are no sellers left to sell?

This is what Dash has been doing for years.

The perfection of Dash’s strategy has been in convincing the entire market that when you “use” Dash or purchase gift cards on Dash Spend, you are “not selling”, and “you are making Dash more valuable!”

This, of course, is blatantly silly and falls on its face, in terms of logic. But the results speak for themselves. Once everyone has sold, there will be no one left to sell.

Dash got everyone to really think “Selling makes Dash more valuable” so sell, and they did.

And as for the reward of this strategy, we will only find out in the future. The breakout has only just started! (Early October 2025)

How is it different than just hodling?

The idea that “Selling makes the price go up” has to be fully embraced and implemented at every level.

I do not jest when I claim it is a brutal strategy.

And everyone must maintain this belief for years… and years.. (at least 8 years, using Dash as a guide) No one in the market can think the price can go up, and everyone must say the selling/spending the crypto for fiat makes it more valuable.

When people “hodl” a crypto, they do it, because they think the market will turn around for them. They will get their turn eventually. This is not the way of the Culling Strategy. The Culling Strategy is 100% commitment to selling, unless you convince everyone that selling is the best and not hodling, it won’t work.

And how do you know everyone has sold?

This is important when everyone in the community says to do something, but no one actually does it. It is, because they don’t actually believe it. They just need to purge all the weak hands, so the price can rise without sellers impeding it.

How did no one see it?

“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”

-Upton Sinclair

What else can we do?

Well those that hope Dash can shift away from the culling strategy will now find it more difficult, as everyone in Dash reaps the rewards of eliminating all the sellers.

But there are positives for people that want to join Dash, just avoid the honeypots that try to trick you into selling your Dash.
These are not bad things, they help remove weak hands from the ecosystem.

Excited for the Future

Dash has built a new chain called, “Dash Platform”. It has Data Contracts and uses a version of Tendermint concensus called “TenderDash”.

You can see an explorer here: https://platform-explorer.com/

I think it’s going to be huge! Data Contracts, Tokens, NFTs, Groups, and they are all available now, builders have just scratched the surface of Dash Platform!

Check out for more: https://docs.dash.org/projects/platform/en/stable/docs/intro/what-is-dash-platform.html

I do hope Dash embraces a different strategy for the future, Dash has a DAO that governs the direction of where it will go in the future. Come participate and you can change the future of Dash!

To start this, we will first show an example of what I call the “naive” approach. Then we will move to a better way and explain the major improvements it has over the first.

Naive Approach

The Data Contract would contain the following properties.

1. recipientId (INDEXED)

2. senderKeyIndex

3. recipientKeyIndex

4. encryptedMessage

5. $ownerId (Document Default Property - Indexed)

6. $createdAt

7. $updatedAt

The recipient would use the recipientId to query the messages from the sender. And the sender would use the $ownerId to query messages, they have sent to the recipient.
The senderKeyIndex points to the encryption key of the sender’s identity keys, and the recipientKeyIndex points to the decryption key of the recipient’s identity keys. (Assuming this is using ECDH, and standard AES-CBC)

Some basic outcomes of this data contract is that there would be a new document for each message, so let’s say it costs 3-5 cents to create a document then each message costs 3-5 cents.

If you have multiple friends on DashPay, the only way to know if you have a new message from a contact, the DashPay dapp would have to query each contact and determine based on the latest message document, check if the user has seen the latest message.
This means if you have 50 friends/contact requests then you have to perform 50 queries to determine if there are any new messages. (This could slow the app down as number of contacts grows)

Thoughtful Approach

The Data Contract would contain the following properties.

1. recipientId (INDEXED)

2. senderKeyIndex

3. recipientKeyIndex

4. encryptedMessageArray**

5. messageTip** (INDEXED)

6. $ownerId (Document Default Property)

7. $createdAt

8. $updatedAt

First Improvement - Cost Efficiency

The first major change for this approach is that no longer does each document correlate to a single message, but multiple messages are stored in a single document.

(encryptedMessage -Naive Approach) becomes (encryptedMessageArray -Thoughtful Approach)

The encryptedMessageArray stores multiple messageObjects, so there are now multiple messages in each Message Document. Each messageObject contains content, timestamp, ifEditted (flag), and any other data the user wants.

The major improvement here is that instead of creating a new document each time you want to send a message, you just update a document. If the cost to create a new document is 3-5 cents, the cost to UPDATE a document is < 1 cent! (could be < 0.5 cents)

And you can store dozens of messages in a single message document! Having a much lower cost to the end user means they will be much more likely to actually use the feature!

(There is more that goes with this improvement as a single property can only store 5kB, so there would likely be multiple encryptedMessageArray properties in a single document.)

Second Improvement - Ease of Use

*** Notification Feature ***

The Thoughtful Approach includes an indexed property called messageTip**
This property acts as a flag for the querying of Platform Data. The sender’s dapp will ensure that only their latest sent message document to a recipient will have the messageTip = TRUE. The implications are as follows.

Now instead of having to query each contact request. The user can perform a query like this:

[[messageTip, ‘==’, true],

[recipientId, ’==’, user’s ownerId],

[$ownerId, ’in’, [array of user’s contacts (their identityIds)]]

This means that the user can now query 100 of their contacts in a single query, instead of having to do a single query for each contact.

(THIS MEANS A VERY FAST CHECK FOR A NOTIFICATION SYSTEM in DashPay! There does need to be a tracking database in the dapp that keeps a timestamp on when the last time the user read messages from a contact.

BUT NOW THE CONTACTS WITH THE LATEST MSGS CAN POP TO THE TOP OF THE LIST JUST LIKE “TEXT MESSAGES” DO ON YOUR PHONE!!)

Third Improvement - Future Extensibility

The messageObjects can also store things like TXiDs, so that the user can send a payment and then after an hour or a day or whenever they want, they can add payment data to a TX.
But it doesn’t just have to be TXiD’s, it could be Document Id data for NFTs or other Platform use-cases.

MORE INTERESTINGLY (added a days after initial posting - TL)
You could include “Payment Requests” in messages:

1. Payment Amount

2. Index of next address to use

3. And what its for in the message content

Including a “Payment Request” flag in the message object could trigger the dapp to handle the necessary functionality.

In Closing
The Thoughtful Approach is a much better message implementation that can be utilized on Dash Platform.

1. Way cheaper for the end user (5x to 10x)

2. Faster notification system once you open DashPay! (like Text Messages)

3. Future Feature Extensibility - Attach TXiDs or other data maybe for other Platform Documents usecases.

If you want the full indexing to go with the full queries that this needs, just message me on Discord.

This is a link to the first article and it explains Proof-of-Cost and Stable-Cost Tokens: First PoC Article. Probably need to read first to understand what follows.

What do the growth phases for a stable-cost token look like?

No one really knows until we actually make one, but it’s fun to have a hypothesis and then see what we got right and what we got wrong.

So I think we should begin by separating the primary and secondary markets. The primary market is the stable-cost issuer, and the secondary market is the buy and sell orders placed by the stable-cost token users. As this will signify large turning points in the growth phases of a stable-cost token.

Phase 2 and 3 are probably the most painful phases, just to foreshadow.

Phase 1 – a boring beginning

(Primary market - supremacy, secondary market - nonexistent)

So probably for the first several weeks, its pretty boring.

There will probably just be sporadic issuing of tokens. (Not really a market)

If there are large price swings in the asset price that the stable-cost is based on, it probably won’t have much of an effect, because token holders probably don’t hold that much and it’s just enthusiasts trying stuff out.

So the secondary market doesn’t really come into effect until purchasers have accumulated a sufficient amount of a stable-cost token such that the cost of posting a sell order on Dash Platform is only a fraction of the cost of the sell total.

What this will do is leave a bunch of random sell orders that people issue to just test out Dash Platform features, but that don’t really entice people into a market. (E.g. someone has a sell order for 2 stable-cost tokens valued at 5 cents. But it costs 2 cents to process the order, so its not worth it to purchase such a small order.)

The reason for this is that stable-cost tokens inherit a principle that drives Dash Platform usage, the principle is “The value derived from usage must be significantly greater than the cost to use.”

For example, if you are going to sell $10 in a token, you probably won’t mind if the fee to sell is only 5 cents, a very small percentage (.5 %). But you would mind if you sell $0.10 worth of a token and the fee is 5 cents, because that would be (50%!)

I call this effect, the “Scaling Advantage”. This is what will also drive the secondary markets advantage over the primary market.

So until people accumulate 10s or 100s of dollars worth of a stable-cost token, they will probably not participate in secondary markets.

One way to improve this stage could be for stable-cost issuers to set a minimum purchase of at least $1 worth of stable-cost tokens, so there are fewer un-viable (in an economic sense) sell orders.

Phase 2 – Stop & Go (but in the wrong direction)

(Primary market- dominant, secondary market – small signs of life)

The price action of the stable-cost tokens will be sporadic and seemingly completely contrary to the price action of the asset its based on.

The reason for this is that, because these will just be people trading and only placing orders probably once a day. And when the price goes up, you will see some sell orders appear a few hours later, but because the stable-cost token market price will be whatever the very last filled order price, it will seem to not move. Then after many hours when some sell orders are filled the stable-cost price will rise some. Only for the asset price to drop and now it seems like the price of the stable-cost is way overvalued for a really long time.

The stable-cost tokens are not broken. This is all to do with very delayed action on the part of the participants and not an issue with the stable-cost coin itself. It’s just there are very few participants.

If I had to guess at this phase, there are many users with at least $100 in a stable cost, and maybe a dozen sell orders get filled in a day at most.

So there are probably large sell orders that sit on the market for hours or days at a time. But as the price moves around, people place some buys.

We are still pretty far from being “stable”, the participants are just figuring out that if more people used this then it could be interesting.

The only advice I have is that the Stable-cost token needs to keep growing. People will continue to mostly make purchases from the stable-cost issuer when they decide the asset price ratio is advantageous to them.

Phase 3 – Too much slippage

(Primary market and secondary market control swings back and forth)

“This is a terrible stablecoin” that is what many will say, but this will be an improvement from Phase 2 where people just said, “This stable-cost thing does not work.”

During this phase, there is a pretty steady issuance of stable-cost tokens for several hours a day, every day.

There are beginning to be continuous activity of orders (several an hour), but there is too much slippage.

So there are many orders being placed, so the price seems to be more accurate, but it feels more like its an illusion, because even though the price (the value of the most recent sell order that was filled) says one thing, if you were to try and buy any sizable amount, the price would move significantly against you.

Price is moving more accurately, but the liquidity leaves much to be desired. My advice is to just keep growing.

Phase 4 – Relative stability

(Primary market and secondary market are just features now, the stable-cost trends with the asset price well enough)

These phases are not concrete milestones. As new participants join with large new pools of capital or old participants leave to go into other things, there may be days where what seemed like everything was working then it falls back to Phase 3 or even 2, but then after awhile it’s stable again.

These are the most important things for the market:

1. The stable-cost issuer maintains an accurate cost-basis for the tokens at issuance.

2. The more participants and the larger the circulating supply, the greater the relative stability will become.

Cui Bono? (answer: Dash Holders)

So we have described different phases of growth, but who are these people participating and maybe more importantly “Who Benefits” from all this?

Stable-Cost Issuers earn commission on the sale of tokens and their profit growth is directly linked to the growth of their stable-cost token.

Stable-Cost Users get a variety of different relatively stable liquid assets with which they can trade or invest in.

Dash Evonode operators get massive gains from the issuance of stable-cost tokens. See let’s say a stable cost has issued $9,000 dollars worth of tokens with a cost basis was 3 cents per token, then they have transferred 300,000 tokens and that $9,000 dollars of Platform credits (gas) went straight to the Dash EvoNodes.

THIS IS BIG! ** ALL BE ADVISED ** There is a bit of irony, if stable-cost tokens do work as I describe then Dash will appreciate greatly, unfortunately this means that stable-cost token holders in other assets like a dollar stable-cost, gold stable-cost, btc stable-cost, etc will not benefit from Dash’s appreciation… BE ADVISED

To summarize, what this means is mostly Dash investors will be using the stable-cost tokens in the beginning and for a significant time after. And probably most crucially, people will probably buy into Dash and then begin to participate in stable-cost tokens.

With all this, we now know who will be participating and how stable-costs grow, so hopefully everyone has a clearer picture of what stable-cost tokens and its ecosystem look like going into the future.

If you need to dive into Dash Platform to understand how that works, please visit: https://docs.dash.org/projects/platform/en/stable/docs/intro/what-is-dash-platform.html

PART 1: Start at the Beginning

What I want to do with this explanation is get to a USD stable-cost token and explain how its stable, but we have a long way to go.

I will start at the beginning, because you have to understand Proof-of-Cost!

So we are going to use an example, with a token issuer who is going to operate the token with zero profit, this will make it as simple as possible to explain Proof-of-Cost(PoC).

So lets say, you (the token issuer) have a token. The tokens don’t really have a market value, because you are the only person with the tokens and no one else even knows that they exist.

Scenario 1: The Bankrupt Token Issuer

This is the irony of the token issuer, to even give a single token to someone else, it would mean you(the token issuer) has to pay to send the token to them. Let’s say it costs 3 cents (in Dash Platform credits) to send a token, so you pay 3 cents in Dash credits to send someone else (the token recipient) a token.

You (the token issuer) are now down -3 cents. The token recipient has a token with a value of 0 cents, because they did not pay anything for it.

Now we said the token issuer was going to operate the token with zero profit, but NOT that the token issuer was going to bankrupt themselves sending tokens. SO HOW Does a token issuer break even sending tokens???

Scenario 2: The No-Profit Token Issuer

So now let’s say the token issuer, who doesn’t want to go bankrupt, says, “I will send anyone 1 token, if you will pay me with a credit transfer (Dash Platform credits) the 3 cents to send you the token.”

Someone (the token recipient) now sends 3 cents to the token issuer. The token issuer takes the 3 cents and spends the 3 cents to send 1 token to the token recipient.

Now the token issuer is break even

Received: 3 cents - Spent: 3 cents = Profit: 0 cents

The token recipient is down -3 cents and has 1 token. Therefore, the token has a value of 3 cents to the token recipient.

PART 2: There is no cheating Proof-of-Cost

So people that read this are probably going to need to reread this part multiple times to really understand, why Proof-of-Cost is really any entirely new consensus mechanism.

So please feel free to read it again.

So we have from Part 1: How a token issuer can break-even (i.e. no profit).

But we have to put another condition around what the token issuer is allowed to do, and you will see this is all to maintain accordance with Proof-of-Cost, and to explain it, I will present a valid example and then the invalid example. Invalid means it breaks/violates PoC!!

Example 1: Maintaining Valid Proof-of-Cost

Lets say someone wants a lot of a token, and they know that the token issuer wants 3 cents for every token. The token recipient then sends 30 cents to get 10 tokens.

The token issuer must then perform 10 separate single token transfers. So that the cost basis remains the same for each token. 10 token transfers at 3 cents each = token issuer received 30 cents and spent 30 cents

With separate single token transfers, the token issuers maintain compliance with Proof-of-Cost. (Cost basis is 3 cents per token: 30 cents spent / 10 tokens issued = 3 cents per token) PoC is Maintained!

Example 2: Token Issuer VIOLATES Proof-of-Cost

Lets say a token recipient sends 30 cents to a token issuer for 3 cents a token and instead of conducting 10 transfers of single token, the token issuer attempts to cheat the system and simply issues a single token transfer with 10 tokens…

1 token transfer at 3 cents = token issuer received 30 cents and only spent 3 cents

The single transfer for 10 tokens violates Proof-of -Cost! The token issuer would then have only spent 3 cents to send 10 tokens and could profit/pocket the 27 cents!

(Cost basis is 3 cents per token: 3 cents spent / 10 tokens issued = 0.3 cents per token) PoC VIOLATED!

The token issuer has therefore broken from Proof-of-Cost!

Proof-of-Cost Enforcement

And with this violation, what does it mean or how does one prevent the violation and/or enforce compliance. We all know that code enforcement is weak, see Ethereum DAO Hack. So we need a much stronger enforcement mechanism, and we have it. Market Enforcement!

Because anyone and everyone can verify and authenticate the Token Issuer Actions (bc Dash Platform), they (the token issuer) can never cheat unless they want to destroy their token.

Because no one would trust the token that is not in compliance with Proof-of-Cost, it would fall to zero value.

-Interlude-

Part 3 and 4 will be an example with a dollar stable-cost token. Part 3 will explain how the cost-equilibrium is driven by the market when the price is not changing.

And Part 4 will show the dynamics of a dollar stable-cost when the price of Dash increases and when it decreases.

This all hinges on Proof-of-Cost, see parts 1 and 2 to ensure you understand this new consensus mechanism.

-End of Interlude-

Part 3: The Cost-Equilibrium of a dollar Stable-Cost in a stable market.

So the market forces operating on the stable-cost tokens are always trying maintain them at the cost basis that the tokens are issued. We can see this clearly when the market is stable. “Stable” meaning the cost is not changing.

Let’s just walk through the 2 scenarios to verify. And I say the 2 scenarios, because that is the only 2 options that a stable-cost can do, go up in price or down in price.

Scenario 1: Trying to pump the price

Let’s say someone tries to PUMP the stable-cost token, well let’s say it cost 3 cents to issue a token, but someone tries to bid up it up to 6 cents. And I say bid up, because there will be buy and sell orders on Dash Platform. (If token issuance is the primary market then the market of buy/sell orders is secondary, but important!)

So what happens when some tries to bid up the stable-cost token THEN EVERYONE would start selling their tokens for 6 cent tokens to him (the pumper) and then purchase 2 tokens for 3 cents each. Effectively, everyone doubles their holdings and the pumper gets half of what he could have purchased.

The only person that has lost out is the person trying to pump, and because anyone can get issued more tokens at the token transfer cost then the price will never go much above the issue cost.

So in scenario 1 the price returns back to the issuing cost.

Scenario 2: Trying to dump the price

Let’s say someone tries to dump at 2 cents. Well everyone else knows that every token costs 3 cents to get, and if someone is selling at 2 cents then they are essentially giving away 1 cent (3 - 2 = 1) per token.

A 33% discount, so no one will purchase tokens from the token issuer until the market order of 2 cents has been filled. Then if people want more they will have to purchase at the token issue cost. And everyone knows that each token is worth 3 cents, because of Proof-of-Cost (see Parts 1 and 2), the person dumping is just giving away 33% of their tokens value.

So once the sell order of 2 cents is filled, the market price returns to 3 cents. The person dumping the token has lost 33% and the price has returned to the issuance cost.

In both of these scenarios, we see that the token price returns to the issuance cost. I call this mechanism the cost-equilibrium and it is driven by market forces.

Part 4: The Cost-Equilibrium of a dollar Stable-Cost in a dynamic market

This is it, the dollar stable-cost token in action.

I can’t reiterate Proof-of-Cost enough, none of this works without the unshakable foundation that is Proof-of-Cost. See Part 1 and 2.

And to understand the dynamics, make sure you understand Cost-Equilibrium from Part 3 and how it drives the price to the issuance cost through market forces.

Scenario 1: Price of Dash goes Up!

Lets say it cost 3 cents(in Platform credits) to send a token to anyone. Then the dollar-Stable-Cost token issuer will require anyone to send him say 3 cents and the recipient will get 1 token of dollar-Stable-Cost. (This means the 1 token has a value of 3 cents.)

So let’s say you purchase 1 dollar-stable-cost token for 3 cents(in platform credits) when the price of Dash is $25.

But then the price of Dash shoots up to $50. Now let’s say you want to purchase another dollar stable cost at 6 cents (in platform credits, same number of platform credits but the fee increased because Dash price increased), but now you receive 2 tokens.

What does this new higher token issuance mean? Well because you already have 1 dollar stable-cost token that you purchased for 3 cents when Dash was at $25, you can still sell it for the original 3 cent value.

The cost-equilibrium that we discussed in Part 3 still applies. The token issuer because they are a dollar-Stable-Cost issuer will maintain an accurate ratio between the dollar and Dash, so that the token issuance amount maintains an accurate cost issuance at the time of issuance.

Scenario 2: Price of Dash goes Down!

So lets say you purchase 1 dollar-stable-cost token for 3 cents(in platform credits) and the price of Dash is $25.

But then the price of Dash goes down to $12.50. Now lets say you purchase another dollar stable cost at 1.5 cents (in platform credits, same number of platform credits but the fee decreased because Dash price decreased), but now you receive 0.5 token!

What does this new lower token issuance mean? Well because you already have 1 token that you purchased earlier when Dash was at $25, you can still sell it for the original value of 3 cents.

The cost-equilibrium that we discussed in Part 3 still applies. The token issuer because they are a dollar-Stable-Cost issuer will maintain an accurate ratio between the dollar and Dash, so that the token issuance amount maintains an accurate cost issuance at the time of issuance.

As you can see the dollar stable-cost operates just like any other stable, I would like to thank my deep disgust for stablecons for driving me to discover stable-costs.

Part 4.5: Some caveats

With a stable-cost in a dynamic market, there is now 2 checks that market participates must ensure to know if a Stable-Cost issuer is not violating the Proof-of-Cost. The token issuance must correlate based on the time of issuance with the actual ratio of the asset-to-Dash, so like it should match the price charts of the assets.

Also stable-costs when they are small will not react with immediate action, and only as they get larger with more participants will they stabilize quicker and have less slippage for buy and sell orders. The cost-equilibrium mechanism is not an immediate correcting phenomenon. Its just something that the market drives toward.

Part 5: Stable-Cost Issuers are Competitors

So if as the title of this part says that the Stable-Cost issuers are competitors, well that implies they are competing for something.

So this part 5 brings in the missing part that we left out in the beginning as to not over complicate the explanation, and that part is the PROFIT for the stable-cost issuer.

We described a no-profit token issuer in Part 1-4, but that is not how people operate in a market. They want to profit and see reward for the work that they have done.

And the way a stable-cost issuer earns profit is they add a small fee to the transfer cost.

Example: Stable-Cost token issuer fee

If it cost 3 cents to send a token, then the token issuer who let’s say wants to earn 2% commission, will require 3.06 cents (in Dash Platform credits) to be sent to him (the token issuer) in order to send a token.

THIS IS VERY IMPORTANT! The Stable-Cost issuer can only earn a fee on the issuance, they cannot issue any tokens to themselves to fund the stable-cost operation, this is a direct VIOLATION of Proof-of-Cost!!

But stable-cost issuers don’t just compete to have the lowest fee, they also complete on the accuracy of their ratio of the “asset-to-Dash” (e.g. dollar-to-Dash, gold-to-Dash).

They also complete on the speed of orders for token issuance is completed. Because let’s say one stable-cost issuer can issue new stable-cost tokens in 20 seconds once the credit transfer from the token recipient is received by the token issuer, but another takes 5 minutes.