gnosis / conditional-tokens-market-makers Goto Github PK

This forum thread highlights some issues with our current AMM contracts (impermanent-loss if an outcome is known prior to resolution), along with an alternate design that would mitigate this issue in the conditional investment / Gnosis Impact use-case. i.e. when we have pairs of markets with different collaterals.

Rather than the current AMMs that trade outcomes with the same collateral, we should create an AMM that trades outcomes with different collateral. Markets that trade horizontally, rather than vertically.

If we were to create markets for the above using the current AMM, they would be vertical (yesDai <> noDai, and yesGNO <> noGNO). The LP splits their collateral into outcome tokens and a market is made between the collateral and each of the outcome tokens for that collateral. Users buy outcomes from the AMM using collateral, or sell outcomes back to the AMM for collateral.

In the proposed horizontal solution, the LP would split their collateral (Dai and GNO) and then deposit the yesDai and yesGNO into one AMM (yesDai <> yesGNO) and the noDai and noGNO into another AMM (noDai <> noGNO). To participate in the markets, users would split their own collateral and then sell the unwanted outcomes to the AMMs.

This is primarily useful for the conditional investing / Gnosis Impact usecase.
For example, if I have Dai and want to buy GNO, but only in the case that the event occurs.
I would split my Dai into yesDai and noDai, then sell my yesDai for yesGNO.
If the event occurs, then I get GNO at whatever the market rate was when I made the trade.
If the event does not occur, I get my original Dai balance back.

As an LP, I am market making between between tokens that will either both have a non-zero value or both have a zero value, so my risk is analogous to providing liquidity in other, non-prediction market, AMMs.

Where can I find this contract?

 import { Fixed192x64Math } from "@gnosis.pm/util-contracts/contracts/Fixed192x64Math.sol";

Also a link to where all the dependencies can be downloaded would be good to have

Problem
A trader classically buys C(q')-C(q) from the LMSR for current and trader-desired quantity vector q, q', resp. This isn't what's implemented in LMSRMarketMaker.sol.

Fix
Documentation explaining how the actual implementation is derived from C(q')-C(q).

Thanks to @cag for the explanation!

protofire/omen-exchange#1593

See #29 for the original context of this issue. I cannot reproduce this error though. From @fvictorio:

I get an error when using 9/10 outcomes:

Runtime Error: revert
Revert reason: create2 failed
Doesn't happen for 6 or less. I didn't test it with 7 or 8 outcomes so I don't know exactly at which point it stops working, but I can find out if it can help you.

I tested this in ganache so I don't have a link to the failing transaction, but can do it if you want.

These are the arguments that are triggering the error in ganache:

salt: 79932
conditionalTokens: 0xD86C8F0327494034F60e25074420BcCF560D5610
collateralToken: 0x9561C133DD8580860B6b7E504bC5Aa500f0f06a7
conditionIds: ["0xc64342d07a96343f150eab7da7d653af79431b0c8e5af72a898b0d99eb87112f"]
gas: 4% (expressed over 1e18)
initialFunding: 0
distributionHint: []

Ok, now I really can confirm it works on Rinkeby for 10 outcomes:

Once an outcome is known, users are able to drain some (potentially most) of the liquidity from the AMM (see this thread).

Two potential solutions:

1. Allow the oracle to report when an outcome is known, in response the AMM would strop trading that outcome.
2. Allow LPs to provide liquidity between specific outcomes.

In both cases, the risk still exists in the time between the result becoming known and the when the oracle or LP can respond.

Contract Link: https://github.com/gnosis/conditional-tokens-market-makers/blob/master/contracts/Create2CloneFactory.sol

Issue List:

• Multiple Solidity Version Specified, while only one is required in Line 1.
• No proper documentation specified.

Currently, the LMSRMarketMaker has an abstract base class MarketMaker which is unused by anything else AFAIK.

Also, there's a set of contracts targeting the FixedProductMarketMaker with pretty different set of requirements and dependencies.

It might be good to turn this into a multi-package repo with lmsr and fpmm packages or something.

Issue
Lines 87-100 of contracts/LMSRMarketMaker.sol provide an outdated explanation for how offset is computed (from back when logarithms/powers were using base-10).

Fix
In brief: EXP_LIMIT is actually 184 * ONE, not the stated 127.5. Sum of 256 values of 184 bits always fits into 192 bits and 192 + 64 (64 from how fixed-point pow2() works) = 256 bits (the upper limit)

Thanks to @cag for the explanation!