GPv2: Clearing prices <> Uniswap pools

Knowledge Base Archive
1

In Gnosis Protocol v2, we are aiming at integrating different on-chain liquidity sources, starting with Uniswap. This topic is around what Uniswap price our quoted clearing price should refer to.

Example

Let’s start with a simple scenario for illustration:

  • consider the Uniswap pool ETH-DAI that has a current spot price
    p_uni_curr = 500 [DAI per ETH]

  • assume a trader wants to buy 1 ETH (leaving limit prices aside for now)

Now, if the trader goes to Uniswap, they need to spend, say, 510 DAI to buy 1 ETH, which means the effective price is p_uni_eff = 510 [DAI per ETH].

However, this trade moves the Uniswap to a new spot price of p_uni_new ~= 520 [DAI per ETH].

The question is if the quoted price of GPv2 should refer to p_uni_eff or p_uni_new.

Option 1 – effective Uniswap price

[+] The user is guaranteed to receive a price “at least as good” Uniswap, hence this approach is well suited in a version that does not integrate other liquidity sources.

[+] The quoted GPv2 clearing price holds for all items in the solution (limit orders + Uniswap). A trader might not be particularly interested in the a-posteriori state of the Uniswap pool.

[–] Moving the new Uniswap spot price beyond the clearing price might immediately result in trades “in the other direction” in the next batch (e.g., if a trader wants to sell ETH @ 515 [DAI per ETH]).

Option 2 – new Uniswap spot price

[+] When the batch is cleared and there are no new incoming orders, there will also no be any feasible trade in the subsequent batch.

[–] The user pays a higher price than they would directly on Uniswap (i.e., 520 [DAI per ETH]).

[?] In a protocol version with a wide variety of liquidity integrations, the order by the user will likely be matched against another source at a significantly better price than the new Uniswap spot price.

[?] Uniswap receives less than our quoted price (i.e., only 510 instead of 520 [DAI per ETH]), so the uniform clearing price does only hold for regular limit orders. However, this creates a surplus of 10 DAI in the protocol that can be used in various ways (e.g., return to affected trader, distribute to all traders, keep as buffer, keep as revenue, …)

[+] The argument is even stronger for potential prediction market tokens, where a trader associates a personal likelihood estimate with a limit price (i.e., if the trader judges the likelihood of an even to be at 80%, they set their limit price to 0.80 and don’t want the AMM to move beyond 80%).

4 Likes
2

Very interesting question specifically important for illiquid (high slippage) token pairs.

To attract retail customers I think that at least initially we have to make sure orders that quote the exact same price as they would get on uniswap (effective price) are matched most of the time. This is a strong and simple narrative for option 1 imo.

I don’t fully understand the last (PM related) argument around Option 2:

if the trader judges the likelihood of an event to be at 80%, they set their limit price to 0.80 and don’t want the AMM to move beyond 80%

The intuition being that the last few outcome tokens actually cost more than 80ç and thus were a bad investment?
My counter-argument would be that the Uniswap trade could be “abstracted away” by another person “simulating” a single price order. Under the hood they could move Uniswap to 85ç (paying 80ç on average) and then sell the whole lot to the trader at 80ç (satisfying the limit and even making it seem like they got a better price than uniswap is now offering).
Since they would be happy to do that, I think they should also be happy to trade against uniswap at the effective price. In other words, we should not assume anything about their marginal utilities if they cannot specify it.

2 Likes
3

Say the trader has a limit price of at most 519 DAI/ETH, and there’s another trader selling 1ETH for at least 510 DAI/ETH. Is it correct that,

  1. We won’t match the two traders directly because the settling price is too far away (>0.3%) from the AMM spot price of 500 DAI/ETH.

  2. We won’t match trader 1 against uniswap because the effective price of 520 we would offer him with option 2 above is beyond their limit price.

Please ignore the rest if I got the above facts wrong.

The reasoning I was given for having point 1 was that when the effective price is too far away from the AMM spot price, one of the traders (trader 1 in this case) is better off going to uniswap directly.

Side note: I never really understood why we use this distance to the AMM spot prices instead of just computing the effective price on uniswap if the trader went there directly (510) and just adjust their limit price to that value (519->510) to make sure we always offer a better deal. (If there were several traders on the same side as trader 1 their limit prices would be adjusted according to if they all went to uniswap together).

Anyway, the reason I am bringing this again here is that I feel that option 2 of this proposal will make this worst since users now always get a better price on uniswap (when matched fully against it), and that it might need to be articulated with this 0.3% rule: both not matching traders directly based on some “quality guarantee” and at the same time let go of this guarantee when there are no more traders around seems inconsistent.

3 Likes
4
  1. We won’t match the two traders directly because the settling price is too far away (>0.3%) from the AMM spot price of 500 DAI/ETH.

I think could be discussed, depending on how many liquidity sources are integrated. If Uniswap is the only one, then we should definitely focus on price consistency with Uniswap, so likely indeed the two orders shouldn’t be matched. If there were plenty of different (A)MMs, I guess we’d have more freedom to choose our prices.

  1. We won’t match trader 1 against uniswap because the effective price of 520 we would offer him with option 2 above is beyond their limit price.

That’s right (at least if the order can’t be partially matched), because it would be a violation of a “hard” requirement then.