P2P Protocol Based Crypto Asset Derivative Settled in Bitcoin on Discreet Log Contracts
This article describes the details of the press release in 2019/04/19.
Abstact
Blockstream Corporation (BS) and Crypto Garage (CG) entered into a derivative contract that locks the future Bitcoin price in order to hedge the Bitcoin price fluctuation risk against the US dollar. Crypto Garage developed a P2P derivative technology based on the Discreet Log Contracts (https://dci.mit.edu/smart-contracts) initially proposed by Tadge Dryja from MIT Digital Currency Initiatives. In this blog, we would like to share our P2P derivatives protocol, the current deal structure and the implications.
What are Discreet Log Contracts?
Firstly, we would like to introduce Discreet Log Contracts (DLC), which is the key technology P2P derivatives are based on. Tadge Dryja (MIT DCI) proposed the concept of DLC and in his white paper “https://adiabat.github.io/dlc.pdf”, he outlined a cryptographic protocol for smart contracts which “addresses the scalability and privacy concerns and seeks to minimize the trust required in the oracle which provides external data. The contracts are discreet in that external observers cannot detect the presence of the contract in the transaction log.” (Tadge Dryja, 2017)
The DLC model involves three parties: two of which are contract counterparties, Alice and Bob, and the other is an Oracle. Alice and Bob pre-agree on the conditions of the contract and cooperate to make a funding transaction as collateral. They then create CETs (Contracts Execution Transactions) which are based on the Oracle’s pre-commitment (EC-point) related to the maturity date and market price. The Oracle publishes the signature data referencing market price, and Oracle is not involved in the contracts. At the maturity time, the counterparties can refund the payoff based on the pre-condition with signature data from the Oracle.
Please refer to the article below for further details about the model, written by Gert-Jaap Glasbergen, a developer at MIT DCI.
Let’s go through more details of how we applied financial engineering to Discreet Log Contracts in order to create a practical P2P derivative instruments.
Our Approach
As Tadge Dryja described in his white paper,
Discreet Log Contracts are a future contract system which addresses the scalability and privacy concerns and seeks to minimize the trust required in the oracle which provides external data.
From the concept of DLCs, we applied the ideas of financial engineering with the goal of creating a trust minimized Bitcoin derivative. The first type of derivative we focused on was a forward contract. A forward contract is an agreement to buy or sell an asset at a predetermined price at a specified time in the future. At maturity of the contract, there are no bounds to the profit or losses of the counterparties of the contract.
For a derivative to work under the DLC framework, both parties need to post collateral upfront, where the maximum profit and loss (P/L) of each counterparty is predefined in the payoff of the contract.
We took the concept of the forward contract and added an upper bound and lower bound for the P/L of the contract. Such a payoff is called a “Collared Forward”.
Based on this bound, the maximum P/L of each counterparty is known and each party can post the relevant collateral on the blockchain directly on trade date. With the collateral cryptographically secured on the blockchain, there is no need for a 3rd party custodian for the collateral and peer to peer counterparty risk is mitigated.
With a trust minimized Bitcoin collared forward contract available, what are some use cases we can imagine?
Use Case Scenario for Collared Forwards:
1. BTC-settled e-commerce (EC) business looking to secure their profits.
Let’s assume there is an EC site that sources products in USD and pays its vendors at the end of each month. The customers of the EC site buys products with BTC on a daily basis. This exposes the EC site with BTCUSD exchange rate risk when it pays its vendor in USD.
To hedge their exchange rate risk, the EC site can enter into a short BTC collared forward with the Market Maker. Effectively, the EC site hedged the exchange rate price risk of BTCUSD. With the DLC protocol where both counterparty post collateral upfront, the EC site can be assured that the contract will be settled with minimal counterparty risk.
2. Traders looking for leveraged exposure in BTC with mitigated counterparty risk.
The upper bound and lower bound determines how much collateral each counterparty will post. As one example, at a notional 1 BTC of exposure, each counterparty will only need to post 0.15 BTC worth of collateral to the blockchain.
Now, let’s see the contract specification between BS and CG.
Contract Specifications — Financial Engineering:
As we’re exposed to Bitcoin price downside risk by its business nature, we’re motivated to hedge such risk with the trade-off of not taking the upside price benefits. In order to manage the price volatility risk of Bitcoin, we considered entering into “short Bitcoin” position via a derivatives contract.
Hedging risk with a Forward -
Managing the price volatility risk can be resolved with entering into a forward contract — by which, 2 parties agree on exchanging a pair of assets at a pre-agreed price in the future. For example, Alice sells bitcoin to Bob 1 BTC at $5000 a week later. From opposite side of view, this means Bob is obliged to buy 1 BTC at $5000 in the same period of time. With this contract, the price volatility risk is mitigated, but another kind of risk comes to light — the counterparty risk. For example, Bob can decide to not honor his end of the deal, especially when the Bitcoin price is unfavorable and has gone down. If Bob goes bankrupt when market Bitcoin price dropped to $4000, Bob no longer would buy the bitcoin at the pre-agreed price, and Alice has no choice but to sell the bitcoin at market price to somebody else. For Alice, this results in a sunk cost of $1000. We also can think of the opposite scenario. In case Bob defaults when Bitcoin price is up at $6000, Alice can sell it to 3rd party at $6000 and enjoy $1000 ad-hoc gain. On the other hand, if Alice goes bankrupt in the same market situation and Bob is still solvent, Bob will not be able to buy the bitcoin at $5000 from Alice, but would buy the bitcoin at $6000, which is an opportunity cost of $1000.
Traditional collateralization
In the traditional financial space, such risk is managed under a special protocol for exchanging collateral — which is known as “CSA” (Credit Support Annex), placed alongside ISDA master agreement. CSA is customizable per participants, but generally, both parties dynamically exchange collateral back and forth, where the collateral amount is determined based on the current value of the derivatives contract. In a normal scenario, both parties are solvent until the maturity of the contract and each completes their obligation. However, when one of the parties either fails to pay or fails to deliver the required collateral, such party is deemed as not meeting its obligation and the contracts between both parties enter into a termination event. In such an inconvenient scenario, the surviving counterparty utilizes the collateral which — roughly — covers the fair value of the derivatives, and re-enters into a new derivatives contract with another counterparty. The actual deficit from losing the original c/p is minimal as it’s covered by the collateral posted by the defaulted party. In theory, the collateral value is equivalent to the re-entering cost for the new derivatives contract.
The financial industry has used this ISDA/CSA framework for decades where the framework has been tested by many kinds of financial events and has continually updated the rules. To date, it has become a very robust framework and recognized as the de facto standard base contract for any kinds of derivatives transaction.
However, as an adverse effect, now it’s notorious as one of the most complex and difficult agreements across industries, not only because of its legal wording, but from an operational perspective. To accurately carry out a derivatives business that complies with the CSA protocols is no easy task.
In the general CSA framework, collateral is posted for a party who is “currently” exposed to default risk of the other side. e.g. for the case in discussion, when the Bitcoin price is at $4,500, Alice would receive collateral for approx. $500 from Bob, while Alice doesn’t post anything. Then, once the price goes down to $4,250, Alice requests Bob to post additional $250 to cover increased risk — this is called “margin call”. Then, once the price moves up to $5,250, Alice returns the received $750, and posts additional collateral of $250 to Bob. In order to neutralize the exposure for each, they have to exchange collateral over time depending on the exposure. This approach sounds fair, however it involves a lot of operational workload and might be difficult to follow for small market players.
*Here, we assume forward price = spot price, just to make the discussion simple.
Utilizing the concept of collateral pre-deposit
As seen, CSA is a P2P framework which defines a protocol for exchanging collateral between two parties, whose amount depends on the value of the derivative contract. Because the derivatives valuation moves with time due to various factors, collateral exchange would need to be conducted as frequently as possible with no-delay for delivery.
As an alternative, there could be another very simple approach — both parties place enough collateral with a third party account that secures the maximum liability exposure during the trade. The challenge is whether the maximum exposure can be pre-defined prior to entering into the trade.
For the forward trade case, the Bitcoin price has a lower bound and the price can never go below $0. So, Alice’s maximum risk is to be owed $5000. i.e. when the Bitcoin price is zero. Alice buys the bitcoin at $0 from market, and sell to Bob at $5000. The risk is Bob may not pay. On the other hand, the Bitcoin price does not have an upper bound so Bob’s maximum potential exposure against Alice is unlimited. Although such upper bound / maximum exposure from Bob’s view is unlimited, collateral model still works for CSA protocol because it has margin call framework, while with DLC this is not the case.
DLC assumes both parties pre-deposit collateral in the middle, where the maximum profit & loss from the derivatives needs to be pre-defined. Figure 4 illustrates the PnL (profit & loss — in Y axis) explained by Bitcoin price (X axis) for forward short — left — and spread option — right — broken down to a combination of options. Note, forward short contract can be broken down to a “long put” part and “a short call” part — a so-called “synthetic forward”. This means, when the market is below strike, Alice has a right to sell bitcoin at $5000, and when market is above, Bob has a right to buy bitcoin at $5000 (Alice is obliged to sell bitcoin at $5000, in other words.) For the DLC model, Bob has to place collateral for his obligation against Alice’s long put option. At the same time, Alice has to place collateral for her obligation against Bob’s long call option — this is impossible as exposure from Bob to Alice is unlimited. In addition, it is significantly inefficient for capital consumption to place the full amount of collateral.
Structure and Pricing
Now, following the basic concept described in the previous section, several derivatives specs have been determined as follows.
- Hedge Term : 1 week
- Strike(s) : long put spread — lower side strike, as well as short call spread, upper side strike — both sides to be 20% distance ratio from spot bitcoin price.
Although our ultimate goal for this derivative transaction was to hedge the Bitcoin price fluctuation risk without taking counterparty risk, in order to limit the maximum exposure for each side, we decided to add a cap and floor on top of the short forward position — a collared option. As shown in figure 4, right side, such collared option can be broken down into 2 parts, CG’s long put spread — shown in GREEN color in the picture, and CG’s short call spread — shown in RED color in the picture.
The trade off is finding the optimal conditions among a) the collateral amount required to hedge certain amount of bitcoin i.e. leverage or capital efficiency, b) the Bitcoin price range where the derivative can work as a good proxy for a hedge — is the spread option range wide enough? c) how long does the hedge works, d) the option premium, and e) minimize volatility & time-decay impact for derivatives valuation.
The most important condition is the Bitcoin price range. e.g., if we can only cover +/- 5% price range for asset with over 60% volatility, it doesn’t make any sense to enter into such derivative as such asset price would easily go outside of the range.
According to the historical Bitcoin price movement for last 1 year, the price stays within +/- 20% range in 90% (two-sided) probability for a 1 week time horizon. This means, if a counterparty posts us 20% collateral for one-week maturity put spread option, we can protect our exposure to Bitcoin with 95% (one-sided for down) confidence. Therefore we decided the derivatives contract maturity to be 1 week, with 20% collateral posting i.e. 5x leverage. Knowing the appropriate price range as +/- 20%, we can go back to our original aim in replicating the “forward” position: we sell the call spread option with a strike price that hedges up to +20% price increase, and using the option premium from the call spread offsets the purchase price of the put spread option that hedges up to -20% price decrease.
Eventually, the total position including original long Bitcoin position becomes a Range Forward position as illustrated in figure 5, below.
For pricing logic and parameters, we used the following model:
Black-76 model — a modified Black-Scholes model adopted to futures- / forward-based option.
Reference market parameters:
- futures price — referred several major online derivatives exchanges’ futures price to find out the term premium for 1 week, then estimate theoretical forward price extended from spot price.
- implied volatility — referred major online derivatives exchange, as well as historical volatility, then came up with estimate around 70% p.a.
On the 9th of April (Tokyo time), Blockstream (BS) and Crypto Garage (CG) agreed to enter into the option transaction as shown below. For the premium calculation, we priced a simple put spread & call spread based on the assumptions as addressed above. The premium calculated as very close to the theoretical forward contract value. This is because both high-end and low-end strike levels for those 2 options were far enough from spot level, and the duration till the option expiry was short enough.
Note that, strictly speaking, simple call spread / put spread pricing is not perfect for this case because we defined the maximum payoff in bitcoin (as we’re on the Bitcoin blockchain), and there was a slight extra value from BS’s perspective in case that underlying price moved beyond upper or lower boundaries, e.g. in case Bitcoin market price fixed at $6500 upon option maturity, Option 1 expires and BS gets back 100% of the posted collateral, and for Option 2, BS shall exercise the right and 16mm satoshi shall be delivered to BS. The dollar value of 16mm satoshi varies based on the Bitcoin price as of the delivery date — $1040 for the given scenario, which is more than $1000 (= $6250 — $5250) with $40 of windfall. However, the possibility to meet such conditions was small enough and the pricing impact was minimal, so we didn’t price in such value into the premium calculation.
then a week later, the option transaction matured with the payoff result as shown below.
We made the above-mentioned contract on the Bitcoin blockchain using DLC.
Now, let’s turn these contract specifications into Bitcoin transaction specifications.
Transaction Specifications — Bitcoin:
The transaction is divided into 3 parts:
- Fund Transaction (“Fund Tx”): Initial collateral posted by party A and B.
- Contract Execution Transaction (“CETs”): All the possible transaction outcome for the settlement date is recorded on trade date.
- Closing Transaction (“Closing Tx”)
Anyone can check each transaction in a block explorer (such as blockstream.info).
1. Fund Tx: Initial Collateral posted by party A and B.
TX ID: 20af6746488f73ef532ed77758d9bb554757fdb139fd82737819f25243de4682
The collateral each party posted is the maximum profit and loss exposure each counterparty has for the respective derivatives trade. In this example, each counterparty posts about 0.167 BTC. This collateral posted includes the transaction fee for creating a block on the blockchain.
The collateral amount is posted and secured on the blockchain with the above transaction input and output.
The transaction inputs are the UTXOs of party A and party B. The transaction outputs are a 2-of-2 multisignature address and the transaction fee for creating this transaction block on the blockchain.
This transaction is linked to the following items, that is already mentioned the “Contract Specifications — Financial Engineering:” section .
The slight difference between the transaction information and the financial contract is that the transaction fee of Bitcoin is, of course, necessary.
2. CETs: Party A and B have thousands of signed Contract Execution Transactions (CETs).
TX ID: b1e499ab67995aaf6b72a1f06faafecb0d18073b4ebb6b93b29a70ddb4aa09f0
The purpose of the CETs is to pre-record all the possible settlement payoffs of both counterparties. For the settlement payoff to be realized, the transaction needs the signature of both parties and the Oracle’s signature. The Oracle is a neutral 3rd party that broadcasts the BTCUSD exchange rate with an Oracle signature at the maturity date of the contract.
At the maturity date of the derivatives trade, when the Oracle broadcasts the BTCUSD rate with Oracle signature, either party A or party B acts to broadcast the corresponding CET.
If one of the counterparties does not tell the truth and picks a payoff scenario differing from the rate quoted by the Oracle, that counterparty loses all its funds and those funds will go to the counterparty who did not cheat.
This transaction is linked to the following items that are already mentioned in the “Contract Specifications — Financial Engineering:” section .
3. Closing Transaction (“Closing Tx”)
TX ID: 7bec8455e0c9060e4ee6653ab20acb95d3b5f5a2d624f855948aeccaac0b57c3
In the case that either counterparty does not act on the maturity date, the transaction is deemed as delayed. When a delay happens, whichever party realizes first can take out the entire collateral. This mechanism is in place to make sure either party sends a signature at maturity.
This transaction is linked to the following items that are already mentioned the “Contract Specifications — Financial Engineering:” section .
Limitations and challenges of P2P derivatives
In the above contract, the collateral is locked in the Bitcoin protocol until the contract expiration date. Execution prior to the contract expiration date, modification of the content after the contract, and cancellation can not be performed. (If both counterparties agree, then modification of the terms of the contracts is possible.)
Because distribution to each counterparty is from locked collateral, the payoff of the contract has upper and lower limits.
In derivative nomenclature, this is a European-type option trade with upper and lower limits.
To further enhance P2P financial products, we are currently working on adding to the lineup American-type options and developing a feature to dynamically change the collateral by margin calling, etc.
Furthermore, the payoff is in terms of BTC. We plan to add further support by integrating with the Liquid Network, a sidechain network developed by Blockstream. With the integration of Liquid, our P2P derivative can support assets issued on Liquid, such as a USD token. With the availability of a USD token, the contract can be settled in USD and collateral in USD can be used.
As Tadge Dryja points out in the white paper of DLC, there is also a problem of “Risk of Trusted Oracle” in DLC. Since the settlement of the contract is dependent on the Oracle’s output of a reference rate, we are working on methods to better protect the Oracle from DoS attack and how to create a fair reference rate to reduce the risk of manipulation are issues we are aware of and are addressing.
Conclusion
Crypto Garage implemented a “P2P Protocol Based Crypto Asset Derivative Settled in Bitcoin on Discreet Log Contracts” and conducted a transaction with Blockstream. We confirmed the validity of the concept and at the same time confirmed the constraints and issues.
We are aware of the trade-off between minimizing counterparty risk and capital efficiency of a financial product. With this transaction as a starting point, we will continue our work in developing P2P derivatives and find practical uses for the future.
We are happy to discuss new ideas related to P2P derivatives. Please contact us at info@cryptogarage.co.jp.
Let’s architect Crypto Finance!
