anthonyleezhang
commented
5 years ago I will also say that I am a big fan of the basic idea of mining contracts -- the most important thing IMO about designing derivative contracts is not necessarily the details of their design, but first and foremost that they "make markets more complete", by enabling a kind of risk transfer which no instrument previously was able to transfer. Pretty poorly designed contracts have persisted for a long time because they were the first to serve a certain risk transfer function, and then "liquidity begets liquidity" allowed them to persist. Sometimes it's better to be first than best!
As far as I know, I haven't heard of any other markets which allow trading mining efficiency risk -- it seems like a real risk which should in an efficient world be traded to agents with better ability to bear and hedge the risk. So good luck!
0xSSoul
travisdmathis
seth-market
allisonlu22
joeykrug
Hey all, I was chatting with @CarboClanC a bit about using MARKET vs UMA protocols as the basis for mining contracts. Here's my thoughts.
On a high level, IMO an important difference between UMA and MARKET is their treatment of margins.
UMA
UMA uses a relatively standard (rel. to classical non-blockchain derivative markets) margin system: participants deposit margin much less than the full value of the contract, and post more margin if prices move against them. This allows leverage, but introduces default risk if prices move suddenly. This is a classic problem in derivative contract markets. There is no perfect solution and margin blowups have happened from the 1800's to today.
There are basically two solutions. One, which is now adopted in most markets, is to "centrally clear" derivatives: all credit risk is assigned to a counterparty, the exchange. So when I'm long oil futures on the Chicago Mercantile Exchange, I don't need to worry about the shorts' credit risk: I just need to worry about the CME running out of money. Could happen, but I'm "sheltered" from specific information about counterparties.
Two, which I think is what UMA does, make contracts bilateral instead of centrally cleared, and then I have to worry about credit risk: the guy who's short for my long might just blow up and not be able to pay me. This is not in principle an insurmountable problem, but introduces a bunch of systemic risk. When prices are relatively stable everyone is fine. When prices start jumping around a lot, everyone simultaneously starts worrying about everyone else being insolvent, and things can potentially get messy. (This happened in '07, '08 as there were a bunch of OTC financial derivatives -- ppl all simultaneously started worrying not about the risks they were trying to hedge, but whether the guys they hedged their risks with are solvent. Which is unpleasant.)
Which brings me to...
MARKET
MARKET protocol has what I think is a very elegant solution to the margin blowup problem, which I think has one crucial design flaw.
MARKET says, rather than designing a contract which covers the whole range of movements of an index between 0-infinity, we'll just cover movements within a certain band (min + max bound). This is very cool because we can then allow participants to post margin covering completely the band. The system then has 0 default risk! But people still have leverage, because e.g. if the band is 2 units wide, you can hedge with 20% the value of the full contract.
Very elegant -- a lot simpler than "top-up margin" systems and with no risk whatsoever of default.
Of course, it can't be perfect -- the problem is what do to when the index moves outside the upper/lower bounds. Here is where I disagree with how MARKET protocol handles things. MARKET simply closes all contracts when the index moves outside the bounds. IMO, this is a strange design choice. Suppose I am planning to run my miner to produce bitcoins for the next year. I buy a mining futures contract to hedge my risk. Suppose there is a sudden spike in production costs; the index spikes above the max and my contract closes after 1 month. I no longer am hedged against mining costs movements for the rest of the year!
This design choice has a few flaws. First, it's more difficult to price the contract as rather than predicting what the price will be on average over a year, one would have to solve a pretty involved stopping time problem. Second, it's in principle vulnerable to manipulation -- if anyone can mess with the oracle and cause a single spike, they can force all outstanding contracts to settle.
There is an alternative design which I think may be slightly more robust, a "censored corridor design: upper- and lower- censor the index. For example, suppose we set upper and lower bounds of 4 and 8. If the index movements are like this:
2 3 5 6 7 9 8 6
We just use the following "censored index" in our contract:
4 4 5 6 7 8 8 6
This introduces "basis risk". So does the MARKET protocol design. It just introduces a different kind of basis risk. MARKET generates uncertainty in when the contract settles. My "censored corridor" design means that the contract is not useful to hedge against extreme movements in the index (neither does MARKET), but doesn't introduce uncertainty in when the contract will settle.
Also, the corridor design, I think (not a programmer), is relatively easy to "hack" onto the existing MARKET protocol: just define corridor_index as:
corridor_index = max(lowerbound, min(upperbound, index) )
And then trade contracts on corridor_index.
Overall I like the MARKET protocol design, I just think that in many cases my "censored corridor" design may make more sense than the "settlement at bounds" design that MARKET currently uses.
I'm quite new to the DeFi space so apologies for any silly misunderstandings or mischaracterizations in the above