Tile layout make-over

[da-kami]

Next funding rate information

• Timestamp when it will occur
• Costs

Historical:

• When was the CFD opened?
• When was the last funding round and at what cost?

As part of this we want a makeover of the tile. Please ping once picking up this ticket.

[bonomat]

I thought I'd post some of the mock-ups we have:

[thomaseizinger]

I really want to see the dollar value of margin, P/L and payout in UI. The first thing after opening a CFD I did today was opening a converter and calculating the initial P/L in dollars.

[bonomat]

I really want to see the dollar value of margin, P/L and payout in UI. The first thing after opening a CFD I did today was opening a converter and calculating the initial P/L in dollars.

I see how this is confusing but you need to change the way how you think about this financial instrument. Since your collateral is Bitcoin profit and losses are measured in Bitcoin and not in Dollars.

I think P/L in Dollar terms is confusing. Think of this:

• Assume you have 0.1 BTC as margin at $50k/BTC.
• Price increases by 10% to $55k You still have 0.1BTC in

You now have

• 0.1 BTC in margin = $5.5k
• you made 0.01BTC in unrealized P/
  --> what's your P/L? $550? What about the $0.5k you earned by just holding your maring? So $6.05k (5.5k+550)?

now, BTC drops to $45k/BTC

• 0.1 BTC in margin = $4.5k
• additionally you made a loss of 0.01BTC
  --> what's your P/L? -$450? $4.05k (4.5k-450)?
  --> how would you represent this number in %?

[thomaseizinger]

I see how this is confusing but you need to change the way how you think about this financial instrument. Since your collateral is Bitcoin profit and losses are measured in Bitcoin and not in Dollars.

I understand all of that. But my issue is that when I went long, I had a dollar price displayed (quantity is in dollars). So I am thinking: I put 100$ in, then I also want to see my P/L and payout in dollars.

We'd obviously have to settle on how to exactly calculate that based on what you wrote above but the fact I am investing in one currency and only see my gains in another is confusing to me.

[klochowicz]

as a user I would love to see an estimate of payout dollars. Doing a google search for an estimated payout every time I wonder how much I gained/lost from my invested quantity is too cumbersome 😭

[da-kami]

Here is my "list of things" I consider "missing" for CFD positions in the UI atm:

• opening datetime of a CFD
• last rollover datetime (I think this has to be independent of the opening datetime to be able to do a proper calc)
• closing price (once closed)
• event that will close the CFD (should be updated with every rollover)
  • relative time until the event
  • event id (--> it has to be verifyable! - best would be link to Olivia explorer so one can also look it up in case needed)

I don't think all of these have to be immediately visible, some could be hidden. But we have to be able to access this information.
Open for discussion :)

[thomaseizinger]

I assume all of your "datetime" values are possibly relative. For example, I'd like to see: "opened 7 days ago" and not "opened on 14/12/2021". Rollover as such is tricky to display. I think that one should probably be expressed in terms of the funding rate, i.e. "next funding period in 3h" and next to it, it should show you how much you will get charged!

I am less convinced about the event ID, I think that is almost a technical detail that should be hidden behind some "advanced" switch in the UI, or debugging info. Element has a "view-source" action per message for example:

[bonomat]

Can you explain why the date is relevant?
For me the date is irrelevant and all I need to see is:

• opening price
• current P/L
• accrued interest (funding rate) (might be better if included in the current P/L )
• next funding rate (e.g. per hour/ per day)

[da-kami]

This is in line with the values I usually care most about when looking at positions.
One thing I am not sure about is if the opening price is so important, but I guess it is in terms of validation.
Seeing just the Current P/L percent (and potentially BTC value) is not enough, the opening price is needed to make sense of that.

[thomaseizinger]

As long as we have a notion of displaying multiple positions (and not adding them together), the opening date is how you mentally differentiate them.

"The one I opened yesterday". "My position from last week is doing well."

If we wouldn't be technically constrained, all the contracts should be added together I guess? We could display them as one and simply limit that you can only sell your position in the same quantities as you bought them because we obviously have different DLCs on chain.

[bonomat]

As long as we have a notion of displaying multiple positions (and not adding them together), the opening date is how you mentally differentiate them.
"The one I opened yesterday". "My position from last week is doing well."

You use the opening time to differentiate between multiple positions. Shouldn't we use a different identifier there?
I think we can just number the positions (e.g. #1 is the first opened position)

When I look at an asset I bought, I don't care when it was bought, I only care about if I would make a profit or loss if I sell it today or how much the price has to move (up or down) so that I make a profit.

I'd only like to see the date in a extended view of the cfd position to verify if the opening price makes sense compared to the traded price on other exchanges.

[thomaseizinger]

I didn't realize it until now but we do we even have tiles or mutliple entries at all?

We can only have one position right? Shouldn't that one change in quantity and what we are currently displaying is actually the order history?

[bonomat]

Good point. I think we will go with the multiple entries for quite a while. But eventually it would be cool to combine it.
For that we would need to allow to partially close a position.

[da-kami]

I didn't realize it until now but we do we even have tiles or mutliple entries at all?

We can only have one position right? Shouldn't that one change in quantity and what we are currently displaying is actually the order history?

We do have multiple positions and tiles. Each CFD is it's own setup. I don't think you can accumulate it into one position. We could try, but that would make difference price (...) even more confusing.

[da-kami]

Can you explain why the date is relevant? [snip]

In addition to what @thomaseizinger said (i.e. the association of the CFD with time, "the CFD I opened yesterday") this is also needed for:

1. Verifyability: I want to be able to check that the price displayed as opening price is actually the price that was the opening price at the time.
2. The association of "how long has this already been going", i.e. how old is my position. Of course you can also calculate that from e.g. what was the initial margin and how much of that did I already pay in interest (...), but the date helps me with not needing to do that.

[bonomat]

Verifyability: I want to be able to check that the price displayed as opening price is actually the price that was the opening price at the time.

+1 on verifiability: I can relate to that. I'd only like to see this in an extended view though.

The association of "how long has this already been going", i.e. how old is my position. Of course you can also calculate that from e.g. what was the initial margin and how much of that did I already pay in interest (...), but the date helps me with not needing to do that.

Why is the date it was opened or the duration relevant?
I assume you want to verify that the subtracted amount of your margin makes sense? E.g you have 0.05% per day, and the position was open for 10 days, so you lost 0.1% only because it was opened for 10 days?
Imho it is really hard to learn something useful from it because in these 10 days the price has very likely moved as well.

[da-kami]

Me insisting on the opening price might be related to the current experience of "having it open for 7 days". I never know how far I am in and that stresses me.

Let's assume we will have some form of funding round display, and have perpetual CFDs.
See only the "next funding round" won't be enough for me. I would need some indicator of the accumulated costs as well (+potentially over time in an extended view).

But I think you are right, I would not necessarily need the initial opening timestamp. I do still associate my CFDs with time at the moment, but am not sure I'd need the timestamp with the funding round display being integrated.

[thomaseizinger]

We do have multiple positions and tiles. Each CFD is it's own setup. I don't think you can accumulate it into one position. We could try, but that would make difference price (...) even more confusing.

I think from a financial point of view, positions are per trading pair and you sum up the quantity. The different opening prices only affects your unrealized P/L. Isn't that what BitMex does?

[da-kami]

I assume all of your "datetime" values are possibly relative. For example, I'd like to see: "opened 7 days ago" and not "opened on 14/12/2021". Rollover as such is tricky to display. I think that one should probably be expressed in terms of the funding rate, i.e. "next funding period in 3h" and next to it, it should show you how much you will get charged!

I think the time until potential expiry (until oracle event) should be relative.
When it comes to the opening time I would probably say: Both the timestamp and the relative time (maybe display the relative time but have e.g. a tooltip with the timestamp). This is for verifyability again. I want to be able to verify that the displayed opening price is sane. I think it would be great to be able to do that.
Note: We might not need this immediately, but I think we should thrive for being more transparent than what's currently out there.

I am less convinced about the event ID, I think that is almost a technical detail that should be hidden behind some "advanced" switch in the UI, or debugging info. Element has a "view-source" action per message for example:

Totally fine with "hiding" is in advanced information, but I think we have to at least plan for displaying this. This is vital information for verifyability!

[klochowicz]

For my use-case, having absolute times even for the expiry/next oracle event is crucial. I put a event/reminder for exact time it would expire - one can set-up a tooltip or something to show the relative time when hovered over, but the absolute time IMHO is most useful.

[bonomat]

Maybe important to point out: your CFD does not have an expiry. The DLC does. Hence, in an ideal case, the CFD does not expire.

If you are online 24/7, and your DLC gets renewed every hour, do you have a dynamic reminder which gets pushed forward by 1h as well? :P

[da-kami]

We do have multiple positions and tiles. Each CFD is it's own setup. I don't think you can accumulate it into one position. We could try, but that would make difference price (...) even more confusing.

I think from a financial point of view, positions are per trading pair and you sum up the quantity. The different opening prices only affects your unrealized P/L. Isn't that what BitMex does?

How would that work given all the different parameters (quantity, leverage, price -> liquidation price)?
I think it might be possible, but I am not sure to thrive for it (yet). I think it will make the user interface more complicated to understand.

Consider: How would you be able to "close" part of this complete position then? I don't want to be forced to close all of my positions at once...
We could potentially group the positions into one big long/short. But again, not sure that actually makes things easier (to understand).

[bonomat]

How would that work given all the different parameters (quantity, leverage, price -> liquidation price)?

for a combined position the leverage is irrelevant. The quantity and margin gets summed up and with it you can calculate the total liquidation price.

It's hard to achieve for us though because we don't have a combined liquidation then but each position has its own liquidation price.

[da-kami]

It's hard to achieve for us

I think given the current solution it is impossible to achieve. It would be very misleading, because with a higher leverage part of your accumulated position would get liquidated, but you might not see that if accumulated!
Now with the price crashing I can also see why the liquidation price can be important. If I have a risky position I will see to mitigate my losses faster and close before I get liquidated.

We could try to make a view where we group by position, i.e. show all Long positions in one group, but I would not try to apply calculations to create accumulated position views, I'd treat each position separate for now in terms of display and actions.

[da-kami]

After some discussion about user interface and product design with @thomaseizinger here is a summary of some of our findings.
What is described here should help us to envision what we eventually will have in terms of setup and display. If we can agree on the long term vision we can see how to reach it in terms of adapting what we currently have.

Our most relevant finding is:

The user interface depends strongly on what we regard as CFD "position".

At the moment we regard each DLC that is set up as CFD position that can be open or closed.
We allow multiple DLCs that are shown as CFD in the UI irregardless of the fact that we could accumulate positions, because essentially we bet either on "price going up" (long) or "price going down" (short) and any new "position" would be either of those two.
We should likely go away from this approach and "only have one position".
I.e. there is only one position open and one can add/subtract from it.

Let me try to outline what this means in terms of setup and display:

1. The taker opens an initial LONG position with maker A:
   1. The DLC is set up with the maker
   2. Lock is published on chain
   3. The position is shown in the UI
2. The taker lets the application run and the CFD rolls over X times:
   1. Transactions are changed offline, no changes on chain
   2. Display is the same taking funding rate into account when calculating P/L
3. The taker opens another long position with the same leverage at a different price with maker A:
   1. We spend the previous' position lock transaction into the new position
   2. Any rollover that already incurred has to be calculated into the new position, i.e. the initial payout of the accumulated new position take the previous position into account.
   3. We publish a new lock transaction that spends from the previous lock transaction.
   4. Note: The liquidation price is different for the new position
   5. Note: I think this is limited to positions with the same leverage. Otherwise a "changed" liquidation price does not make sense.
   6. User interface: Since the old position is implicitly closed with the new one there is only one closable position displayed in the UI.
4. The taker opens another long position with different leverage at a different price with maker A:
   1. We keep the old position as is and set up a new one in parallel.
   2. We publish another lock transaction independent of the previous lock transaction.
   3. The new position (both long) is grouped together with the other long position but one can close them separately. The user interface can show one accumulated view, but it has to be expendable to see that there is positions with different leverage inside that can be closed independently.

I think opening a short position should behave the same as the long, but instead of adding to long we would subtract, i.e. a counter position would reduce the position size. Given the same leverage, we would also spend from the previous lock transaction.

All of what is described is limited to one maker. If we have multiple makers we will have to have multiple separate positions set up and displayed, because we don't have a "marketplace" as such. If positions are tradable we can probably achieve to combine it again, on a different level.

[da-kami]

One can combine them: You'd need to calculate an average opening price and derive the leverage from there i.e.

* you had 100 contracts long

* at $50k/btc

* leverage 2
  --> You had to put up 0.00100 BTC .

* Now you go 200 long

* at $100k/btc

* leverage 5
  --> You have to put up 0.00040 BTC.

(50,000*100 + 100,000*200) / (100+200) = 83333.33

Your average entry price is $83,333.33/BTC. The total margin you provided is 0.0014BTC which is a leverage of quantity / (margin * price_opening (derived from 1). which is 300 / (0.0014 * 83,333.33) = 2.57.

Your liquidation price can then be derived from this which is left as an exercise for the interested reader :D

I understand that this is mathematically possible, but I am not sure if that is what a user would want from a CFD product.
If I open a position with high leverage I will treat it very different than a position at a lower leverage! For a position with higher leverage I will monitor the market more closely and will treat is as a position that I want to close very short term, whereas with lower leverage I might keep it open for longer.
Note, that we might also have different interest for different leverage - which again could be combined, but I am not sure that is what I'd want.

Granted, it might be worth exploring a combined view - but I would definitely not want to have positions with different leverage combined on a blockchain level! I am not even sure how much the combined view would help me, because I would potentially find it misleading.

[bonomat]

@thomaseizinger

What is the reasoning for that? I can see some complexity here because we have to continue to monitor the old commit transaction that would only spend from the first lock transaction. If we instead spend the first lock transaction, we automatically invalidate the entire tree of previously created transactions.

Yes, it doesn't come for free. The complexity should be the same complexity as when rolling over: you invalidate the old commit transaction and need to monitor it for the lifetime of the channel.

@da-kami

The advantage of combining a position as described is that you don't have to monitor two positions (if you have one with a lower and one with a higher liquidation price) but you have one combined position with a single liquidation price.

[thomaseizinger]

What is the reasoning for that? I can see some complexity here because we have to continue to monitor the old commit transaction that would only spend from the first lock transaction. If we instead spend the first lock transaction, we automatically invalidate the entire tree of previously created transactions.

Yes, it doesn't come for free. The complexity should be the same complexity as when rolling over: you invalidate the old commit transaction and need to monitor it for the lifetime of the channel.

Hmm, so you would punish in case an old commit transaction is published? What speaks against spending the old lock transaction into the new one? That design would make this error path simply impossible which seems desirable. I can't see any downsides in doing that or any benefits in leaving the old lock transaction in place. Do you see any?

[bonomat]

As discussed on a call: the main downside of spending the old lock transaction and using it as an input for a new one is an increased transaction fee through bigger transactions.
Meaning, if we don't closed but just have an additional lock transaction we have N+M inputs. N for the taker, and M for the maker. If we spend the old lock transactions, we have N+M+1 inputs, where as 1 is coming from the old lock transaction.

[thomaseizinger]

Thanks for putting it in writing here!

Agree that we could save some transaction fees here.

As discussed:

• The savings get smaller once we adopt taproot
• Not having to manage N lock and commit transactions but just one significantly reduces complexity
• To save even more transaction fees, implementing a proper L2 with the maker is likely the much more rewarding option and will be easier from the standpoint of always just having one lock transaction.

If we still agree to this, please leave quick thumbs up!

Edit: Once confirmed, I'll write up an ADR to capture this!

[bonomat]

Archiving this due to inactivity.