Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Cases #5

Open
norswap opened this issue Mar 25, 2022 · 2 comments
Open

Use Cases #5

norswap opened this issue Mar 25, 2022 · 2 comments

Comments

@norswap
Copy link
Contributor

norswap commented Mar 25, 2022

Been thinking about the use cases for the protocol a bit more.

In the current form, here's what I see the use cases are:

  • short many assets
    • Normally, to short a token you need to have either a structured product (option, perp) or to be able to loan a token against stable. But many/most tokens don't have options or futures, and can't even be borrowed.
    • Our protocol is not permissionless: we'd still need to whitelist tokens, but we can be a lot more aggressive with it than other projects, because we don't require tons of liquidity for it to work! When launching a pool, we'd subsidize the imbalanced side via inflation (and low use = low subsidization), and rely on incentives for people to take the other side.
  • short costlessly
    • Shorting can be costly: if you use borrowing, then you need to pay a low % annual fee. With options, the cost of the option (the premium) is lost forever. Perps are fairly similar, in the sense that most often long pay shorts via the funding rate. We at worse have no costs for shorts, at best they get paid via imbalance incentives.
    • There will be probably be some low (think 0.1-0.3%) charge on transactions, but no inherent cost to staying in a position.
  • arbitrage
    • Arbitrageurs are users too =)
    • Mostly, people coming in to benefit from imbalance incentives.

This is not bad, but I think we can have more use cases:

  • short any asset
    • In the future, it will be possible to access the L1 block hash from L2 (theoretically, this can already be done but then we need to take responsibility for transmitting the blockhash from L1). This will enable us to list any asset for which we can find a good price oracle on L1!
    • I'm particularly excited about the prospect of tracking the floor price of selected NFT collection. A cryptopunk is pretty unaffordable, but since pool tokens can be fractionalized, you could just purchase 0.0001 cfdCryptoPunk.
  • leverage
    • This one requires some protocol work, but I think it's doable: basially we'd let people borrow X $C against a collateral of Y $C where X > Y. The trick is that this borrowing is done atomically when depositing into a pool, and the X balance is credited to a new "virtual account" (e.g. the address is the hash of the user's address). The only way to access the virtual account is to withdraw from the pool (and "repay" the loan) or for the loan to be liquidated. These loans can be permissionlessly liquidated if they get below a minimum health threshold, and liquidation will be incentivized.

I'll update this when I have more ideas. One I'm thinking through at the moment is prediction markets!

@norswap
Copy link
Contributor Author

norswap commented Apr 3, 2022

Some thinking through the "prediction market" use case.

  • Parimutuel betting. Imagine betting on a binary outcome (true or false), you make two pools of money (one for each outcome), and after the outcome is determined, the winning side gets the other side's money, propotionally to their stake in their side's pool. So this is essentially our pooling mechanism, except we don't have to take the other side nor balance the pools.
    • This gives "implied odds", i.e. the ratio of the pool sizes. If there is twice as much money in the "yes" pool than in the "no" pool, it is implied that a "yes" outcome is twice as likely as a "no" outcome (66% vs 33% probability).
    • The problem with the parimutuel system is that it needs to stop trading well in advance of the resolution of the event, and that it's always most advantageous to place your bets right at the end (since that's when you'll have the most information).
    • So it doesn't make for a great prediction market, since you only have interested implied odds right as trading becomes suspended.
    • Real prediction markets are actually "futures" for a prediction. Both the $YES and $NO token trade in the [0, 1$] range such that price($YES) + price($NO) == 1$. At the end, you can cash out the winning's side token for 1$ while the other side's is worth 0.
      • The problem is always how to make sure you can settle redemption at the end. One solution is matching every YES with a NO (via an order book, aka continuous double auction in this case). Another solution is for the protocol to take the other side of every bet (like we do with normal pools). The big problem with that is that we can't incentivize the pools to balance: we would screw up the price, which give us implied odds. We don't have this problem with normal pools (which when you think about it are just continuous prediction markets for the future price!) because we really on an external oracle to give us the "real" price. Since we can't incentivize the balancing of the pools, we open the protocol to high inflation.
    • On Optimism, we already have a parimutuel protocol called Thales, though its functionment since to be relatively more involved than the description I made above (notably because it enables longing/shorting assets just like our protocol, which is not a binary outcome). I need to read more about it, esp. these articles.
    • There seems to be some ways to use the parimutuel mechanism to build prediction markets. See these slides (math-heavy, probably a couple hours to figure that stuff out) for info. From a cursory reading it does seem the market maker (i.e. the protocol, or some sort of stakers/liquidity providers) do take some risk, which the formulas are designed to minimize.
    • Another really interesting design I found was a bundle-based approach. In this case, you let people purchase a bundle for a $YES and $NO token for 1$. This is the only way to mint these tokens and ensures solvency. Then it's up to the bundle-buyers to sells these tokens at a price that they think will make them a profit — they're essentially market makers. They could pick some odds they consider likely and sell at a premium, or some other mechanism (Uniswap-style AMM?) could be used. Note that in the case of two AMM pools (one $YES-$C, one $NO-$C), the prices will automatically balance since if e.g. $YES increases, then $YES + $NO > 1$ and you can buy a bundle and make an instant profit. On the other hand if $YES decreases, then you can buy $YES + $NO from the pools for less than 1$ and make a profit by holding until settlement. This is a really cool approach, now that I think of it, but it has very little overlap with the CFD protocol 😅

@norswap
Copy link
Contributor Author

norswap commented Apr 3, 2022

Another cool use case: gas price futures. Essentially just a pool that tracks the Ethereum (or Optimism) gas price. If you're a protocol that has to regularly make transactions, you can buy these tokens when the gas price is cheap to "lock in" the cheap gas price. On the flip side, network validators could enter the short side, to "lock in" today's high gas price.

The concern here is that sometimes it's very very obvious the price is low, and other times it's very very obvious the price is high. Unlike token price, gas price is not supposed to reflect some kind of fair value price. It can be obviously clear to everyone that demand is high right now for a particular reason, so gas price is high, but that it will come down soon.

The solution would be to encode a premium into the price. The problem is obviously how this premium can be determined. We could up with a formula that compares the pool sizes (excluding protocol position) in order to determine the premium. So when e.g. the pools are unbalanced 10:1, the premium would be extremely high to reflect that the expected price is much higher.

The Alkimya protocol intends to do something like this, although they call it "block space derivatives".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant