# Contracts Simulating Crypto-Fiat Exchanges

The price of bitcoin in terms of fiat currencies (e.g., the U.S. dollar) has tended to be notoriously volatile. Due to this, many people are unwilling to have too much exposure to bitcoin in their portfolio. Unfortunately, the best way at the moment to manage that exposure is by using third party exchanges to buy and sell bitcoins for fiat currencies. Such third party exchanges must be trusted in two important ways. First, the exchange gives customers “IOUs” in exchange for their bitcoin and fiat deposits. The customer must trust that the exchange will later allow them to use these IOUs to withdraw the appropriate amounts. Second, most exchanges operate in an environment of KYC/AML (“know-your-customer/anti-money-laundering”) regulations which require them to collect private identifying information about their customers. Customers must trust the exchange to keep this private data safe.

If the customer is only interested in managing their exposure to the bitcoin price, then an actual interface with traditional fiat banking services is not needed. Instead, a contract associated with a multisig pool can be used to simulate selling some bitcoins from a party to a counterparty at a certain price. The contract is settled at some future expiration time in a way that depends on the bitcoin price at that time.

#### An Example

Suppose Alice has 10 bitcoins and $900 in her savings account. Suppose the current price of a bitcoin is $450. This implies Alice has a portfolio worth $5400 ($4500 worth of bitcoins and $900 worth of USD). Alice may be concerned that over 80% of her portfolio is in bitcoins and wish to bring this percentage down to a more conservative 50%. She could do this by using an exchange to sell 4 bitcoins for $1800, leaving her with 6 bitcoins ($2700 worth) and $2700 in USD. However, Alice is unwilling to trust third party exchanges. Furthermore, Alice does not insist on taking possession of the $1800. She merely wants to ensure that a week from now the value of her portfolio (measured in USD) has the equivalent value as it would *if* she had 6 bitcoins and $2700.

Suppose Alice finds a counterparty, Bob, who is interested in buying 4 bitcoins for $1800 in order to balance his portfolio. Alice and Bob could create a multisig pool with 8 bitcoins — 4 contributed by Alice and 4 contributed by Bob — with an agreement (a contract cryptographically signed by Alice and Bob) that at the end of the week Alice will be paid $1800 worth of bitcoins and Bob will be paid the remainder of the 8 bitcoins. This has the effect Alice wanted by simulating making the exchange. On the other hand, for Bob this has the effect of simulating his portfolio having 4 more bitcoins and 1800 fewer dollars. The only potential problem is if the price of a bitcoin drops below $225 in which case the full 8 bitcoins is no longer worth $1800. In general there will be a “price window” within which the simulation works. The size of this price window depends on the amount contributed by both parties and is derived from the contract.

#### Contracts

A *contract* can be represented by five components: (*a*,*b*,*c*,*x*,*t*). Each of these components can be described as follows:

*a*is a positive number representing the number of bitcoins the party (Alice) contributes to the contract. This is the*party’s collateral*.*b*is a positive number representing the number of bitcoins the counterparty (Bob) contributes to the contract. This is the*counterparty’s collateral*.- c is the price of a bitcoin in dollars at the creation of the contract. This is the
*creation price.* *x*is a positive number with*x*≥*a*and represents the number of bitcoins being sold from the party to the counterparty.*t*is the expiration time of the contract. (This could be represented, e.g., in Unix time.)

The contract represents the selling of *x* bitcoins from a party (Alice) to a counterparty (Bob) at the price of *c* dollars per bitcoin, to be settled in bitcoins at time *t*. This contract should be part of a transaction with an output of *a+b* bitcoins to a 2-of-3 multisig address, controlled by Alice, Bob and an escrow agent.

Suppose the price of bitcoins at expiration time is *p.* Then Alice should be paid* (a-x)p+xc* dollars worth of bitcoins and Bob should be paid *(b+x)p-xc* dollars worth of bitcoins. Note that these sum to* (a+b)p*, as required. Such a payout is not possible if *p* is small enough that *(b+x)p−xc* is negative or if* x>a* and *p* is large enough that *(a−x)p+xc* is negative.

We say the *window of the contract* is the set

{*p > 0*|*(b + x)p−xc ≥ 0* and* (a−x)p+xc≥0*}.

It is easy to see that *c* is always in the window since *bc > 0* and *ac > 0*. The window is always a closed interval with positive lower bound *xc/(x+b)*. If *x=a*, then the window has no upper bound. If *x > a*, then the window has the upper bound *xc/(x-a)*. We say the price *p* is *below the window* if *p<xc/(x+b)*. We say the price *p* is *above the window* if *x > a* and *p>xc/(x-a)*. If the price at expiration time is below the window, Alice should be paid the full *a+b* bitcoins. If the price at expiration time is above the window, Bob should be paid the full *a+b* bitcoins.

If Alice and Bob agree on the price *p* at expiration time *t*, they can sign a transaction paying the appropriate number of bitcoins to Alice’s address and Bob’s address in a settlement transaction. If Alice and Bob do not agree on the price *p*, the escrow agent can determine the price (by looking at third party market data) and sign a settlement transaction. As long as the escrow agent’s settlement transaction is acceptable to either Alice or Bob, the contract can be settled. If an escrow agent signed a settlement transaction using a price that is easily seen to be incorrect, this signed settlement can be used as cryptographic evidence that the agent is untrustworthy.

#### Revisiting the Example

Let us reconsider our example from above. Recall that Alice has a portfolio of 10 bitcoins and $900 with the current price of $450 per bitcoin. She wishes to simulate selling 4 bitcoins for $1800 in order to balance the portfolio. With only this information given, Alice could ensure this with a contract of the form (*a*,*b*,450,4,*t*) where *0<a≤4*, *b>0* and *t* is an expiration time in the future. The choices of *a* and *b* affect the window of the contract.

The contract described in the original example would be (4, 4, 450, 4,* t*) where *t* would be one week after the creation of the contract. This contract has a window of [225, ∞). That is, as long as the price is at least $225 at the expiration time, then Alice will receive $1800 worth of bitcoins as a payout.

Suppose the counterparty, Bob, is only willing to contribute 2 bitcoins worth of collateral. In this case the contract is (4, 2, 450, 4, *t*). This contract has the smaller window of [300, ∞) since *xc/(x+b) = 1800/6 = 300*.

It may be that Alice is willing to accept the risk that the price falls below $300, in which case she will receive the full 6 bitcoins, even though they are worth less than $1800.

Suppose that Alice and Bob are both only willing to contribute 2 bitcoins

each as collateral. In this case the contract is (2, 2, 450, 4, *t*). Here the window has an upper bound of *xc/(x-a) = 1800/2 = 900*. That is, the window is [300, 900]. As long as the expiration price is in this window (at least $300 and no more than $900), the contract can be successfully used to simulate Alice having sold 4 bitcoins to Bob, while only actually contributing 2 bitcoins to the contract. This method can be used by Alice to effectively short the bitcoin price. Note that in every case, Bob is simulating having more bitcoins than he contributes in collateral, so Bob is always effectively taking a long position on the bitcoin price.

The window can be made arbitrarily large or small by choosing large amounts

of collateral or small amounts of collateral.

#### Conclusion

The balancing of a portfolio including cryptocurrencies and fiat currencies can be simulated using contracts and multisig pools. The settlement at the expiration time is performed within the cryptocurrency. As a consequence, the simulation requires no fiat interfaces with traditional banking institutions. Such contracts could provide a way for moving away from traditional cryptocurrency-fiat exchanges and their corresponding legal restrictions.