Crypto AMA with UMA (9.19.19)

Let's please give a warm welcome to Allison and Hart of UMA. 

As a reminder for everyone participating—please keep the discussion respectful at all times.

@hart @allison - can you both start off by giving us a brief bio on your backgrounds as well as how you got started in crypto? And then a short overview of UMA and a brief update on your progress to date? We’ll then be off to the races with questions.

Thanks for having us on the AMA, Spencer! Great to be here.

Hi all, pleasure to be here!

Background: I studied CS way back in the day. I then (rather randomly) joined Goldman Sachs as an interest rate trader in 2005 and worked their for 8 years. For 5 of those 8 years I sat next to Allison. It was an awesome learning experience.

In 2013 I left GS to start a fintech business called Openfolio. That biz was acquired in late 2017 and allowed me to focus on crypto full time. (That said my first taste of crypto was way earlier during my GS days when Fred Erhsam—a fellow GS trader at the time—introduced me to bitcoin. I love him for that 🙂 )

Hi everyone - I’m Allison, the cofounder & COO of UMA, a decentralized financial contracts platform built to enable Universal Market Access. Prior to UMA, I spent ~3 years running credit strategy at emerging markets mobile lending startup Tala, and ~6 years at Goldman Sachs on the Interest Rate Products trading desk.

For me, the route to crypto was circuitous… The bitcoin whitepaper made the rounds on Wall Street back in 2010 - and while I was smart enough to read it, I was stupid enough not to invest at the time. Since then, I’ve spent my career in financial services in a variety of contexts and geographies. Each time, whether I was serving institutional or retail customers, in developed or third world countries, I came to realize that the economic incentives amongst different stakeholders in the system were frequently misaligned. I became obsessed w/blockchain technology when I realized that protocol designers could embed economic incentives directly into the technology itself, incentivizing people’s behaviors when they used that technology. I’ve been down the rabbit hole ever since and jumped at the opportunity to work w/Hart again on this company in early 2018.

The goal for UMA is Universal Market Access (what it stands for). We really mean that. We (strongly) believe we can create the infrastructure that allows for financial products that are universally accessible.

More concretely, UMA is an infrastructure to build financial contracts on Ethereum. It consists of two parts: (1) financial contract templates that are the building block of different types of customizable financial products, and (2) a decentralized oracle design that provides dispute resolution for those contracts.

Our first financial contract template allows users to create synthetic tokens, backed by digital collateral, whose value can track the price of anything! You can interface with it yourself via CLI (github.com/umaprotocol), or our Rinkeby dApp (tokenbuilder.umaproject.org)

Hi guys! Thanks for coming on. 

What types of agreements do you think UMA can power in the future between parties? I guess what is your wish list of use cases over the next 6 months

@allison @hart feel free to finish your intros if you still have background to share before responding, otherwise let's jump into questions.

Previously, we’ve also worked w/the teams at MakerDAO and DDEX to launch a mainnet product, USStocks, which was a synthetic token whose value tracked a major US stock index (https://medium.com/uma-project/announcing-us-stock-index-token-powered-by-uma-and-dai-c394586c575a). Over time, it grew to have over 1M dai of collateral locked inside the contract. It was a great POC of our technology and a fantastic demonstration of DeFi composability.

First type we're focused on is what we're call "synthetic tokens". This is what the Token Builder Allison mentioned above is focused around. A synthetic token is simply an ERC20 token that tracks the value of some price feed. (In this way DAI is actually a type of synthetic token). We think this can be a sort of primative for all sorts of concepts. For example yTokens (from the last AMA) are another type of synthetic token, etc.

^^ Hart actually used our tech to create a testnet implementation of yTokens on Rinkeby! It only took a few hours to do.: https://hlambur.github.io/uniswap-frontend

More generally, we’re excited about supporting these categories:

1) All things interest rates, yield curves, and fixed income. This means specific products like yTokens (both for ETHUSD and tBTCUSD funding pairs) that aid in price discovery and also are a building block to enable non speculative use cases for borrowing/lending in DeFi + pave the way for fixed income products.

2) Synthetic local currencies: using Dai to create synthetic local stablecoins for local payments systems and wallets; we’re working with Sempo, for example, to create synthetic Vatu tokens that their users can spend in the island of Vanuatu using the sempo wallet.

3) Offchain or cross chain synthetic assets that go directly to enable Universal Market Access like USStocks, but with local brokerage and wallet partners

4) Composability within DeFi/rehypothecation to create yield enhanced synthetic asset products

Awesome looking forward to following your progress!

Some other interesting example of synthetic tokens (to add to Allison's list):

* Things that track real world assets (like the S&P500, gold, oil, etc)

* Things that track baskets of crypto products (including tokens that aren't native to Ethereum (think like a Coin Market Cap top 100)—or things that short altcoins.

* SwanDAI (one of the ETHBoston finalists—a token that pays out if DAI breaks the peg)

* An Altcoin dominance token (something that tracks the CMC 100-bitcoin dominance—this would be a cool way to profit from the growth of altcoins without taking a directional view on crypto prices)

* ... and there's a whole lot more.

More yToken dets here:

2/ yTokens can be implemented super easily as an @UMAprotocol synthetic asset to create fixed-term loans!

I did this on Rinkeby and pushed to a test @UniswapExchange frontend! You can buy Dec31 yTokens currently yielding ~7.2% here: https://t.co/dJSjbG13SP pic.twitter.com/fXpoNYD7BW

— Hart Lambur (@hal2001) 11 September 2019

Hey guys - Joel here from Outlier Ventures. trying to understand how synthetics will be decentralised (or if they wont be)-will the assets representing the stocks for instance be held by someone at a centralised account? How will their existence be verified.

Hey Hart and Allison!

GOing further on point 3 here

How does UMA's oracle mechanism work?

Great question: this design does NOT a trust or legal structure that knows the underlying assets (a trust is what USDC uses—and Tether is supposed to use, for example). Rather, the design is completely synthetic: the creator of the tokens must pay the change in price of the underlying asset to the holder of the token. The token creator and token buyer could enter into a bet on gold without either of them owning any actual gold.

Thanks (its 4:00 am here) - i'll have to crash. Will catch up conversation when I wake up. 

Hi All! Thanks for letting this group ask you questions today. Traditional derivatives markets trade large notional amounts and processes to enter in these positions and manage the open positions have a lot of things broken that could be improved. In parallel, there's early activity in DeFi markets with exciting new ways of doing things. To what extent could the 2 worlds intersect, in other words could traditional finance benefit from what you're building vs DeFI? Follow up, who do you see as your primary target users? Thanks!

The reason why the token creator does this is because they will be penalized if they do not. This is the similar to how a CDP creator in Maker must add ETH to their CDP if the price drops or else they get penalized (aka liquidated).

Can you describe the UX differences/tradeoffs in the synthetic assets produced by UMA, MakerDAO, and Synthetix?

So Allison and I come from traditional finance backgrounds. We agree that trad finance can certainly be improved, but things work pretty well for the big institutional guys. There isn't a zero to one improvement here.

DeFi has a different flavor. It's much more about the little guy, or creating opportunities or products where there previously weren't other options. We are highly focused on this type of user (and not traditional financal institutions). We think this is where the killer app will emerge... plus it's a lot more fun to build for this user base.

Hi Cole. Our decentralized oracle mechanism introduces the concept of economic guarantees to blockchain oracles. We believe that at scale, any on chain oracle can (and will) be corrupted. So any smart contract depending on external inputs is at risk - scary!

Our oracle ensures that there is no economic incentive for anyone to corrupt it. We do this by creating tradeable voting rights (UMA tokens) with an observable market value. Owners of these tokens vote (Schelling point style) to fulfill price requests from financial contracts that use this oracle. So long as there is an honest majority, we can show that the optimal strategy is for UMA tokenholders to answer truthfully. The cost to bribe UMA tokenholders is the cost to corrupt the oracle (CoC). Because the UMA tokens have no other extrinsic value, they will lose value if the oracle is corrupted - so the max CoC is effectively 51% of the UMA voting token market capitalization. So long as CoC > potential profit to be gained, there is no economic incentive to corrupt our oracle. We enforce this to be true by implementing a dynamic fee policy on margin inside financial contracts that make requests of the oracle, and use those proceeds to buy-and-burn UMA tokens to maintain the CoC > PfC relationship. You can read more here: https://github.com/UMAprotocol/whitepaper

In your oracle whitepaper, I like the framing of designing a mechanism with economic guarantees (i.e. such that Cost of Corruption < Profit from Corruption) but isn’t measuring the true PfC extremely difficult if not impossible?

Awesome. Thank you, Allison!

MakerDAO: take ETH collateral (in single collateral DAI at least) and spit out a perpetual stable value asset. Design a system to make damn sure that stable value asset stays at $1!!

Synthetix: create SNX and use it as collateral to back other synthetic assets. This works as long as SNX has value.

UMA synthetic tokens: take ETH or any ERC20 collateral and use it to collateralize synthetic assets. This works as long as the underlying collateral has value.

We have two strategies to ensure that we can measure the true PfC:

1) All financial contracts must register w/our oracle in order to use it, and agree to the oracle’s fee policy. This includes limitations on the types of margin currency that can be used, and ensure that fees can be collected.

2) Even with registration, contracts could become “parasitic” by passing on oracle results to “parasitic users” that don’t pay the fee, and thus make the system insecure. This is an area of ongoing research, but we have a promising solution that we call “parasitic fuzzing” where instead of returning the oracle result directly to the smart contract requesting it, we “fuzz” the payouts to prevent it from being passed on directly to parasites.

Thanks @hart. Do all UMA synthetic assets have an expiry date similar to USStocks? More broadly, can you walk us through how we should be thinking about expiration dates as investors evaluating the integrity of these systems?

Thanks Hart! That's exciting and clearly distinct from  projects like Axoni and Synswap, which I thought would be competitors of yours after I listened to the podcast.

Interesting re: (2). If that works it would have lots of applications

Tokens with expiry dates are easier because they create a natural mechanism to keep the synthetic token price in line with reality. This is because of the arbitrage that exists when there is a set expiry and settlement. 

For example, say we create synGold with a expiry of Dec31. If synGold is trading 10% below real gold, an arbitrageur would buy synGold, sell real gold, and lock in a 10% profit that he/she would get paid on Dec31. 

This isn't possible with perpetual tokens because, well, they are perpetual. That means you need to resort to other (more complicated) mechanisms to keep the syn token price in line with its target. Maker, for example, has to put a lot of effort into mechanisms to keep their perpetual token inline with its target.

To add on here: from a UX standpoint, all tokens that get created are ERC20s at the end of the day. But how (and why) they get used are quite different. Also, the details of the financial engineering behind them are quite different as Hart pointed out.

MakerDAO: created a CDP portal dApp to allow users to open CDPs and create Dai; most CDP creators use CDPs to get leverage on ETH. The use cases for Dai range from earning yield in Compound, to stablecoin pairs on exchanges, to payment currency, to margin currency in platforms like dYdX or even ourselves.

Synthetix: created a trading platform to allow users to trade amongst different synthetics and SNX; most people use it to get leverage on SNX and speculate on price movements between different synthetics within the SNX platform

UMA: Builders use our financial infrastructure to create innovative products and deliver them to their users in any way that they see fit and makes sense for their UX, whether it’s via a direct wallet integration, dApp, DEX, or other website.

To be clear, we want to support both tokens with expires and perpetual tokens. This is because the UX of a perpetual token is really nice for many use cases—people don't want to "roll" their exposure or manage these tokens that expire. But it is worth highlighting that making things perpetual seems to require more complicated mechanisms.

Hello! Is there a native token for UMA? If not, are you exploring potentially introducing a token?

There is a token for our oracle (what we're calling our Data Verification Mechanism, or DVM). This is currently on testnet. Allison described our oracle design here! https://t.me/c/1477285922/4129

Very cool!

That link doesn't work.

Sorry. It's ^^^ message.

Gotcha, super helpful. Would love for you to expand on what stability mechanisms you foresee UMA issuers using for both perpetual and expiry tokens respectively.

For perpetual tokens, it’s ensuring that tokenholders and issuers have a way to pay each other if the market value of the tokens deviates from fair value. BitMEX perpetuals, as an example, use an 8hr funding payments to make longs pay shorts or vice versa based on where the bitmex perpetual trades vs. the bitmex bitcoin index. This ensures that bitmex perpetual market price converges to fair value at least once every 8 hours. It’s actually economically equivalent to forcing the futures contract to expire and all positions to automatically roll every 8 hours.

MakerDAO dai, as another example, was previously only able to make CDP creators pay a stability fee in the CDP for using their system, but now dai holders can also get paid for holding Dai by lending it out in protocols like Compound. 

In both cases, it’s all about funding: some interest rate (whether positive or negative) that a long pays to a short.

Thanks for coming on, @allison and @hart ! Really love what your team is building. How do you plan to generate revenue? Oracle fees? Anything else?

The oracle is the monetization scheme for both the dev team and the whole network (aka our community of oracle voters). I'm biased, but the thing that I really love about our token economics is that it's not profit-seeking; rather, it will extract the minimum amount of fees (from contracts) required to keep the system secure.

How does your solution compare to competitors' eg Chainlink, Uniswap becoming an onchain oracle, Maker/Compound ecosystem medianizer oracles?

Admittedly hard but important question - what are some ideas to encourage what you call responsible financial innovation? This is different than corruption control. For example, things like mortality swaps, assassination markets, etc..?

In the context of UMA issuers, when tokens expire, that settlement is a natural mechanism to ensure that synthetic token market prices eventually converge to fair value. So issuers and tokenholders don’t really need to do anything except hold to expiry. Deviations from fair value before expiry actually reveal pricing information about what the implied funding rate is.

But it gets more complicated when you try to enforce funding payments AND still maintain ERC20 synthetic token fungibility for a perpetual token. To analogize again MakerDAO: each dai token is fungible whilst each individual CDP is non fungible. But MakerDAO had trouble maintaining the $1 dai peg until Compound came out, and gave them a way to effectively transfer funding payments to dai holders. 

UMA is similar where each synthetic token could be fungible whilst each individual token facility is non fungible. Charging token facility owners a fee isn’t a problem since their positions are non fungible anyway. But having funding payments occur efficiently in the other direction will be a challenge for perpetual synthetics. I think that if we use interest bearing assets like cDai as collateral in UMA token facilities, this would obviate that need but it’s an area of ongoing financial engineering research.

All the designs are just different. Different designs work for diff use cases, and we want to be intellectually honest about that.

Chainlink: programmatic API data delivery. If you need data from an API, you can get it to the blockchain (pretty quickly) via this design. The problem is that if your API data source ever breaks, you're screwed.

Maker/Compound: essentially the same thing as Chainlink, except that you insert a 1-hour delay (or other safe guard) so that a small set of admin keys can pull the plug if things really break.

Uniswap: (after it's hardened): great on-chain resource for ERC20-ERC20 price feeds, but limited to ERC20-ERC20 prices.

UMA DVM oracle: designed to only be used for settling disputes in contracts. As a schelling point design, it relies on decentralized human judgement to resolve disputes, making it resilient to bad or broken API feeds, but also requiring that it's slow and asycnchronous.

Funny you mention mortality swaps, because they actually are a staple of traditional fiat insurance markets 😉 

But in any case I think what you’re alluding to is a question of governance: How are we planning on deciding what types of financial contracts, how much leverage, and what reference price indices we’ll allow in the system? It’s definitely a balance of wanting to support innovation whilst also staying on the right side of both the law and morality. 

For us, we generally allow any incentives compatible smart contract template to interface with the DVM, and leave all other contract parameters up to the individual. We believe that the market will be better at deciding the “right” amount of leverage and what templates are useful than we will be in a centralized fashion. It is also the responsibility of the individual deploying the smart contract to ensure that they are in compliance with their local regulation. However, the UMA DVM will NOT support all arbitrary reference price indices on mainnet, at least from day one (unlike Augur, which supports natural language markets, our DVM depends on well defined price requests). The decision of which price indices to support is up to the UMA tokenholders.

Our philisophy is heavily inspired by layer 2 scaling work (aka the stuff you do Georgios!). Basically the oracle should *only* be used when it needs to be, similarly to how the layer 1 chain should only be used when absolutely needed (in layer 2 design philosophy). We will be writing more on this—what we call "optimistic financial contract design"... although we need a better name... so if you all have suggestions, please suggest!

The analogy we use: you (Georgios) and I could write a private contract in the fiat world under State of New York law. We write that contract without any intention of litigating it. But we know that if we don't follow the terms, we can go to NY court and dispute it. This is exactly how we think financial smart contracts should be written. Most of the time they shouldn't need an oracle—the oracle really functions as a sort of last-resort dispute mechanism, similar to an exit game in layer 2, that is only used when a dispute arises.

That was precisely the essence of my question, thanks. Makes a lot of sense.

15-minute warning. Please get your questions in!

Any last questions?

Alright I think we'll wrap it there, thanks a ton for coming on @allison and @hart! Super interesting system you're designing. 

Final Q's:

- When is the token/mainnet going live?

- Best way for folks to get in touch?

- Best way to stay abreast of project updates?

- Additional synthetic tokens will go live on mainnet in Q4. Oracle and associated project token will launch on mainnet in the next few months.

- Best way to follow along is twitter (https://twitter.com/UMAprotocol) and Medium (https://medium.com/uma-project/)

We are also hiring for software engineers and looking to get in touch with more people interested in buliding or supporting mainnet synthetic tokens. Please reach out if you have any leads!

Awesome. Thanks again guys, and thanks Crypto AMA for asking great questions as always. Until next time 🍿