Thoughts on MARKET vs UMA protocols

[anthonyleezhang]

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

[anthonyleezhang]

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]

Thanks professor @anthonyleezhang!
In my opinion, the "censored index" design is a smart design, which makes the long position's profit and loss curve very similar with that of the European spread options.

[travisdmathis]

Hi @anthonyleezhang this is amazing stuff and I am absolutely thrilled to see this kind of study being done into our work. I think you bring up some interesting points and am deeply flattered with your choice of words when describing our design! We have worked so hard, so to see people understand what we're trying to accomplish is amazing. Very excited to work w/ Carbo Clan to see this to reality.

I think everyone at MP is excited to chat w/ you as much as possible about contract designs and how we can offer new products or improve our existing products. Going to dig into this a bit more before responding in kind, but I'm thinking this becomes a kind of "right tool for the job" thing and using a bounding mechanism that supports the use case.

Bands or Censored Corridor when deploying the contract!

[anthonyleezhang]

@travisdmathis "I'm thinking this becomes a kind of "right tool for the job" thing and using a bounding mechanism that supports the use case." I agree that either early settlement or censored indexes could work, depending on the application at hand (if I'm understanding what you're saying). For this particular application censored corridor seems to me a bit more sensible. (Note also that I just made up the "censored corridor" terminology, there might be standard terminology for this thing already, I'm not sure).

Again, very cool work you're doing, and I'd also be happy to chat more on phone or skype if you'd like.

[travisdmathis]

@travisdmathis "I'm thinking this becomes a kind of "right tool for the job" thing and using a bounding mechanism that supports the use case." I agree that either early settlement or censored indexes could work, depending on the application at hand (if I'm understanding what you're saying). For this particular application censored corridor seems to me a bit more sensible. (Note also that I just made up the "censored corridor" terminology, there might be standard terminology for this thing already, I'm not sure).

Again, very cool work you're doing, and I'd also be happy to chat more on phone or skype if you'd like.

That's exactly it. Basically deploying the contract with the bounding mechanics that work best for the use case at hand. In this case, censored index.

[seth-market]

Hi @anthonyleezhang. I appreciate your time! We’re looking to build the best product possible and your feedback is great.

Why do we close the contract as we get through a bound vs keeping it open?
I think some of these arguments can be made either way. I’ve always thought the certainty and simplicity of settlement at the Price Cap or Price Floor would make it easier to trade and manage which in turn makes it more liquid. Below are benefits of the current architecture (which may be valid in both scenarios).

Capital efficiency
If a band is breached and the contract stays open till time expiration, hedgers must tie up capital to keep positions open which may have little hedging value (the position’s price is effectively fixed at 0 or max gain) but needed to manage risk. With our structure when a band is breached, hedgers take their proceeds and roll into a new contract. This also allows market makers or traders to free up capital immediately.

Hedging costs
Removing the touch component and pricing more like a standard option adds optionality to the product as we can go above and below the bound and increases the cost to hedgers.

Simplicity/liquidity
The optionality mentioned above increases risk for market makers and the overall cost to manage inventory. Closing positions on band breaches limits the number of open contracts for trading and focuses liquidity.

Regarding oracle manipulation, this can be mitigated in the oracle definition and is a function of the reference asset. So, for example, we can use an index of exchanges instead of a single exchange to define a band breach. Further, we can use a vwap of exchanges of some interval. Overall, we agree oracles are prone to failure and a point of further development both for us and the entire space.

Your suggestion of a “censored index” I believe would be very similar to saying these contracts have a Price Cap and Price Floor but only expire on time. This should be very easy to implement with the current infrastructure.

To address price movements outside the band we’ve considered a way to roll up or down strikes. For example, if we get within say 5% of a price band a new contract is created with the price band as the midpoint. Traders who want additional price exposure can then roll into the new contract. A dapp or smart contract can automatically facilitate this roll recreating uncapped exposure and abstracting it from the user.

We would love to speak further on how to improve the architecture. I would be glad to follow up on a phone call when you have time.

[anthonyleezhang]

Yeah, happy to talk. I can do e.g. 3pm or 3:30pm Chicago time tomorrow, does that work for you?

When bounds are breached, contract positions lose some but not all hedging value, because the indices could always go back within the bounds before settlement.

Hedging costs, increased risk for market makers: Assuming you're talking about my "censored index" system, I don't completely understand what you're saying here. I think my system has no more risk than your current system, there is 0 probability of default, and the margins are exactly the same. The difference is purely whether early settlement is a possibility or not. (So I agree with this: "Your suggestion of a “censored index” I believe would be very similar to saying these contracts have a Price Cap and Price Floor but only expire on time.")

I like the "automatic roll" design in principle. I think a simpler way to do this is just to define multiple censored index contracts in the first place. E.g. if the price is 5.5, have censored index contracts for the ranges 4-5, 5-6, 6-7. Agents who want leverage will largely trade 5-6, agents who want additional "disaster insurance" can post additional margin and buy 4-5 or 6-7 contracts. These will naturally be less liquid, of course, but the number of people trying to buy this kind of "disaster insurance" is more limited. Pricing the outside band contracts is somewhat more involved since they're out-of-money so their "optionality" aspect is a bigger component of their value, but their settlement time is certain so this isn't too hard.

My proposed system basically has the benefit that the set of tradeable contracts is somewhat more stable and predictable. Agree that both designs could work, and which is better depends on the circumstance. Also agree that my censored index design is easy to hack on to your current architecture, as I mentioned before, it's just applying a censor function on top of an oracle.

[seth-market]

Tomorrow should work at 3pm central. I will email you. Thanks.

[anthonyleezhang]

@seth-market Yup sure, I'm anthony.zhang@chicagobooth.edu

[allisonlu22]

Thanks for the comments, @anthonyleezhang. I'm the cofounder of UMA - and I echo Travis's thoughts - super cool to see this kind of research being done on our work as well!

We share your view that specific contract design is less important vs. finding the design that's "right for the job" and that network effects can be particularly meaningful in financial markets (BitMEX vs. superior contract designs on other crypto futures exchanges being a prime example). UMA chose to initially design templates that would be differentiated (we were aware of and very much respected MARKET and Augur's work and saw no reason to replicate). We also wanted to keep the financial risks vanilla - barrier designs are simple to understand, but extremely difficult to hedge and typically considered "exotic." Of course, our read of the marketplace might be inaccurate as retail customers (who dominate crypto trading volumes) love products like barriers and binaries that "professional" market makers consider exotic.

Regardless of the contract design, these products typically need an oracle. Our primary research focus is and has been on the security of that oracle. After all, if one can control the oracle, one can control the payouts (or at least force contracts to cancel the risk). While brute force tactics can mitigate the impact of an oracle manipulation, our bold claim is that any on chain oracle can (and at scale, will!) be manipulated, similar to rigging scandals a la LIBOR. We recently presented this work at Scaling ETH and released our code to testnet: https://twitter.com/hal2001/status/1149466877543845888.

We've actually had early discussions with MARKET around using UMA's decentralized oracle as a solution for identifying boundary crosses and for final settlement, as those are currently the largest points of centralization.

We'd love to engage further and hear your thoughts as well.

[anthonyleezhang]

@allisonlu22 I was commenting mostly on the margining system of MARKET, which I think is the main innovation in their design. I just read over your system for oracle security, I think I get the basic design although I haven't thought through the details yet. I actually have a working paper on a related topic, which is manipulation of price benchmarks in cash-settled derivative contract markets. Would be happy to chat! Shoot me an email at anthony.zhang@chicagobooth.edu

[joeykrug]

‪just saw this on Twitter. This proposed bounded solution is exactly how Augur Scalar markets work today Now idk how useful a mining contract denominated in ETH is (ie today), but when V2 launches after the new Dai release is out it’ll be denominated in USD.

[0xSSoul]

‪just saw this on Twitter. This proposed bounded solution is exactly how Augur Scalar markets work today Now idk how useful a mining contract denominated in ETH is (ie today), but when V2 launches after the new Dai release is out it’ll be denominated in USD.

The bounded solution is indeed consistent with Augur Scalar in terms of settlement results. However, Market Protocol fully tokenizes the position and make the position a standard ERC20 token, which is Market Protocol‘s most important feature.

[joeykrug]

I actually don’t think that’s a super important feature (it’s trivial to tokenize anything on chain), but Augur shares / positions are ERC20 tokens and have been since day 1