I would like to share an idea I have for how we can create stable coins on Bitcoin Cash, or at least "stable assets". Please note this is not a technical specification, but rather just a thumbnail sketch of the plan. (I will skip the background explanation and assume you know what stable coins are.) The biggest problem with stable coins is you need tons of capital to support them. For example, Tether is supposed to hold billions of dollars in some bank accounts. I think that if this requirement can be avoided, it will great. What if stable coins could be backed by BCH, not fiat? What if we could simply use Oracles to obtain the proper ratios of BCH to fiat? That's my starting point.

Futures Market

To summarize the idea: We create an open, flexible, and permissionless futures market. The sellers of the futures are effectively buyers of the stable asset. First, we must understand that "stable" is a relative concept. If someone is holding dollars, they might think of those dollars as stable (in fact, this is the common meaning of the term "stablecoin"), but if the BCH/USD trading pair always fluctuates in value, then we always have a position in this market, regardless of whether we are holding Bitcoin Cash or US Dollars.

If Alice is holding US Dollars, and BCH/USD goes up, then she is actually losing money in terms of Bitcoin Cash, rather than having something stable. This may seem obvious to some people, or it may seem like semantics to others, but the point needs to be grasped. Looking it from the opposite point of view: When you hold a stablecoin, you are in essence betting on the price of crypto going down.

Oracles

With OP_CHECKDATASIG, we can validate a signature over a piece of data that is obtained from an external source. So, we can obtain information about the BCH/USD price from some exchange, and use that in a smart contract. Do you see where I'm going with this? Alice and Bob can enter into a smart contract, and use information from the oracle to decide how funds will be allocated. For instance, Alice may believe BCH/USD is going up, and Bob may believe BCH/USD is going down. In this case, Bob is holding a stable asset in US Dollar terms. The unlock script takes the simple form of: Alice Sig on Alice pubkey + Bob Sig on Bob pubkey OR Alice Sig on Alice pubkey + Oracle Sig over data(1) OR Bob Sig on Bob pubkey + Oralce Sig over data(2)

Issues

This concept seems good in principle, but can it actually work? There's a few basic challenges that are obvious. The good news is that there are solutions, so overall the scheme may be possible. First, let's enumerate these challenges: 1. Granularity With a Bitcoin script or BCH smart contract, usually its "all or nothing". Alice can either unlock the coins or she can't. There's no way (currently) to allow Alice to spend part of the funds if, say, the BCH/USD pair fluctuates slightly.

2. Timing If Alice and Bob put their funds into a smart contract, when exactly can they unlock them? It's no good to Alice if she plans on securing her funds for a sustained period, if Bob can simply turn around and close out the contract.

3. Transfer

Usually stable coins can be easily transferred or sent around from one person to another. How exactly can Alice transfer her smart contract to someone else if it depends on signing with her private key? 4. Liquidity

Will there actually be a market for these smart contracts? How will it establish itself and grow? 5. Trust What happens if the oracle fails to publish the information as expected or gives the wrong information?

Solutions

Granularity

To solve the granularity problem, each smart contract can consist of a group of bitcoin scripts, rather than a single Bitcoin script. For example, say the price of BCH/USD today is $500. Alice and Bob each allocate 1 BCH to each of 50 different scripts, for a total of 50 BCH each. Alice wants stability relative to the US dollar, so she makes money if BCH/USD falls, and Bob makes money if BCH/USD rises. If the price is $250 (or less) at the time the contract is finalized, Alice collects all 100 BCH. If the price is $1000 (or more) at that time, Bob collects all 100 BCH. At any price in between, the oracle can calculate how much money each party should get and sign accordingly so that the correct ratio is payed out. In this example, the payout is rounded to the nearest bitcoin, which is 2% of the total contract. More granularity can be added. The only real practical limits to the amount of granularity are transaction fees. Furthermore, additional instances of Alice-Bob pairs can exist using a similar contract (with different amounts) without requiring additional signatures from the oracle. The limitations of risk to each party prevent excessive payouts in either direction (<$250 or >$1000). This limitation can be worked around in several ways. 1) It can be priced into the agreement. 2) It can be rolled into a new contract. 3) Special contracts can exist with deeper reserves. Finally, keep in mind that the contract can also reflect market sentiment and the contract doesn't have to match today's spot price, as is the case with any futures market. Timing To handle the issue of when contracts should exist and expire, we can follow the standard practices in the futures markets where there is a monthly contract. The oracle can release the signatures at a specified time before or after the end of each calendar month. This standardization simplifies everything. Rollover of the monthly contract can be done simply by setting up a new contract. Transfer

Although there isn't an obvious way to transfer ownership of a smart contract from one party to another in an ideal manner, it could be done with the permission of the counterparty, perhaps in consideration for a nominal convenience fee. Say that Alice has a contract with Bob, but Alice wants to sell her contract to Carol, and remember that Alice and Bob can mutually decide to unlock the funds without the oracle. To accomplish this transfer, first Alice and Carol would create a duplicate of the Alice-Bob contract, but using Carol's keys. Then, Alice, Bob, and Carol would mutually create a transaction that sends the funds from the Alice-Bob contracts into the corresponding Alice-Carol contracts. There would be additional inputs from Carol that would then go to outputs belonging to Alice. Each participant would sign their inputs over all of the outputs using Sighash ALL|ANYONECANPAY. The convenience fee to Bob could also be part of this transaction as an additional output that's covered by either Alice or Carol. Liquidity If the solution and software work well people will use it. Assuming there is a demand for the stable asset, then that side of the market is covered. The other side (the BCH/USD bulls) would emerge as a natural consequence of any two-sided market. Price spreads and future prices will be determined by price discovery. The markets can be either exchange driven, or decentralized as solutions emerge. Trust It may be possible to use multiple oracles in a kind of multisignature oracle scheme, although I think this will be unnecessary in practice. The oracle business is built on trust and reliability. There is an opportunity here for exchanges to grow their brand by providing a stable oracle service. For example, if Bitstamp (to pick an exchange at random) started providing this service and everyone used the Bitstamp oracle, that brand would gain more prominence. One bad mistake by an oracle and their brand is tarnished.

There can also be competition among oracle services and different stable assets "backed" by different exchanges. Backed is in quotations here, because nothing is actually backed by funds. The funds are backed by BCH, although collusion and negligence are possible. The participants of the smart contract do not need to trust the exchange with their funds. In the simplest implementation, a non-responsive oracle can be dealt with by mutual cancelling of the contract.

In a slightly more sophisticated scheme, the participants can guarantee return of their own funds without cooperation of the counterparty by first creating transactions that spend the funds back to themselves from the smart contract (before they fund the smart contract), and these payments can be timelocked so that they are only available well after the oracle is due to provide the signatures.

Summary