Re-design usage of quotes / prices

[thomaseizinger]

Currently, we subscribe to BitMex for quotes.

The latest quote is used for:

1. New offers on the maker side
2. Calculating unrealized P/L of open positions
3. Suggesting a price during collaborative settlement

(1) is problematic because when to trigger a a new offer is external to the maker binary and influenced by several things including a significant change in the current price. It would be a lot more natural to have the actual price of the offer also be external to the maker binary.
(2) is just wrong, we should use the index price for this.
(3) is tricky. We don't want to put this on the user and offer them an input field.

Would it be correct to suggest settling based on the current index price @bonomat @da-kami @itchymax @scratchscratchscratchy?

If yes, then we could do the following:

1. Swap the subscription URL to use the index price instead of bid/ask from the current order book.
2. Use that price to calculate P/L
3. Change the new offer endpoint to require a price (and remove the price subscription entirely from the maker).¹

Footnotes

1. This implies that we are no longer doing any P/L calculation for the maker which is currently happening within crate::projection and used by both parties. For now, we can just permanently pass None here for the maker but in the long run, these models should likely just separate and we need to projection modules, one for each binary. ↩

[1010Tom]

Thanks for writing this up.

I agree with (1).

On

(2) Calculating unrealized P/L of open positions
(3) Suggesting a price during collaborative settlement

In my eyes there are two ways how a position can be closed:

1. Market order
2. Limited order

Let's focus only on (1) for now, which is what we have at the moment and leave (2) for the future.

Our collaborative settlement can be seen as closing with a market order as the user is not asked for any input.
He basically opens a position with the same amounts in the other direction and both positions get voided out.
That being said, he would not get the current index price but the current market price (bid/ask).

The important thing here is that the unrealized P/L as shown in the UI is not equal to what he would get. It's an estimate if the position was to closed at the current price.

For me this would mean two things:

1. unrealized P/L is calculated using the index price, and
2. for collaborative closing the current market price is taken.

Ideally, a maker comes up with the price but that's a bit challenging because for us the maker we market sell to is always the same we opened the position with in the first place.
We should keep that in mind for the future. For now, I would take the current bid/ask rates for collaboratively closing.

[thomaseizinger]

For now, I would take the current bid/ask rates for collaboratively closing.

That is tricky to as it would require us to track two different prices. Bid/ask and index. I was hoping to get away with only tracking one of the two within the taker binary for simplicity.

[thomaseizinger]

Proposal from @bonomat in #1290:

Atm: The bitmex price feed is used for the maker to come up with a rate when creating offers and for maker and taker for computing P/L.

A few thoughts:

• Offers are created using the HTTP Api and it's unnecessary to have the binary to provide the price feed, send out the price information via SSE, and then post the price again. This extra roundtrip is not needed and was removed in our personal automation.
  Hence, the maker is no longer making use of the price feed to create new offers.

• The current price feed is used for computing P/L for positions: this is semi correct. The maker's P/L is calculated differently than the taker's P/L

  • maker's P/L: the maker has its own opinion on the price, meaning, his P/L should better be calculated from the outside.
  • taker's P/L: the taker has not an own opinion on the price, he either gets what the maker is willing to offer (for settlement) or what the oracle attests to (force close).

We want to show a P/L to the taker though: we have already two price feeds for the taker:

1. the maker's offers
2. the bitmex index price feed

--> For the taker's unrealized P/L we probably should make use the maker's offers as this is what he would get when settling a position.
--> We let the maker compute his P/L from the outside

Given that we can remove the bitmex price feed altogether.

Note: For a precise P/L computation we should know the payout curve, meaning, if we want to compute P/L from the outside, we will need to expose this information via the HTTP Api.

[da-kami]

I think this is not totally correct, I'll try to rephrase a few things to see if I have a misunderstanding or the outlined solution is incomplete.

The maker's offer does not contain the bid/ask price as the price fee that is currently part of the daemon, but the maker can add a spread.

--> For the taker's unrealized P/L we probably should make use the maker's offers as this is what he would get when settling a position.

Given that there might be a spread I am not sure this would work - I think the price suggested for collaborative close should be the index price, not the offer price of the maker. The idea is, that collaborative close behaves like the closing by the oracle, but at any point in time - so the price used for collaborative close should be the same as used by the oracle.
We can change that constraint, but that might make trading with that maker unattractive.

---

I think we either need the index price within the taker daemon, or we supply the index price for the taker from the outside as well.
We could just treat this as limit order (we don't really have a market order implemented but an inbetween of market and limit, given that the taker sends a price suggestion and the maker accepts/declines a price...) - where the limit is set to market price, so it should always work and the taker does not have a choice.

[thomaseizinger]

Given that there might be a spread I am not sure this would work - I think the price suggested for collaborative close should be the index price, not the offer price of the maker. The idea is, that collaborative close behaves like the closing by the oracle, but at any point in time - so the price used for collaborative close should be the same as used by the oracle.
We can change that constraint, but that might make trading with that maker unattractive.

"Closing" a long position is conceptually selling your contracts to that maker. I don't see why anyone would buy/sell at the index price?

I get the view that you are taking but I think we should move away from that view. I think we should view "closing via the oracle" more as a form of "settling a dispute". It is an exceptional behaviour and thus, using the index price is the fairest thing to do.

In day to day operations, we should think of users trading contracts (buying and selling them) and to do that, you need to adhere to the price that someone offers you to do that.

[bonomat]

I think we agree that non-collaboratively closing on-chain using the oracles attestation is the exception and not the rule as it bears unexpected behavior: you have no guarantee that you get the price you want as there can always be some fluctuations.

As @thomaseizinger said:

"Closing" a long position is conceptually selling your contracts to that maker. I don't see why anyone would buy/sell at the index price?

I think this statement holds (unless the index price is better for the maker, in which case, it is not in the incentive of the taker to go with it).
More generally said, closing a long position is equals taking a short position with the same quantity.

Retrieving this short position always comes at a maker's ask price. Since we can't buy/sell from another maker (yet), we have to take the price from the maker we are connected to.