Fee representation in the UI

[da-kami]

At the moment we display the fees as Total fees like this:

It's the sum of all fees including the opening fee.

In our internal model we came to the conclusion that a positive and negative fee is not that easy to understand. I wonder if we can take this knowledge and change the fee display in the UI into something different.

In #1217 (comment) were discussing using FeeAcount::settle on the projection API as well. That only makes sense if we would change the projection API - and that in turn would only make sense if the consumer (the user interface) requires that. Otherwise we re-implement a conversion from settle to the FeeAccount's balance - might as well use the balance than as currently implemented.

I am not sure that displaying the Total fees is the best / most helpful way to learn about the fees for the user.
We could for example display Long -> Short: {absolute_fee_amount} or Short -> Long: {absolute_fee_amount} - but I am not sure that helps.
I also wonder if users would like the complete fee breakdown. It's easy to say "I want this", but I wonder what users would actually do with this. I am not sure I'd care unless the fees are suddenly super high.
Thoughts?

[luckysori]

I would argue that for UI clarity combining all the fees is useful, since it's simpler and faster to parse, but in that case we need a breakdown.

On the other hand, it's simultaneously a bit confusing to combine all the fees, because they do completely different things:

• Transaction fees are always owed and have to be partly an estimate until the contract is closed.
• The opening fee is always owed to the maker for the taker.
• Funding fees can be positive or negative, change over time and I would expect to be able to know when they're changing and by how much ahead of time.

It is impossible to convey all this with a single value, so I believe we definitely need a breakdown on the UI, plus some tooltips explaining this behaviour.

I am still undecided about the need for a sum total. Perhaps there is no value in "total fees" because what the user cares about is "how much am I earning/losing" overall, indicated by P/L, and "why", which can be deduced from a breakdown of all the earnings and costs.

[luckysori]

I like this idea.

Lock transaction fee and opening fee should be paid out of the wallet and not the margin, ie we should lock up margin + expected miner fee + opening fee

With expected miner fee, are you already covering possible collab_close or commit + CET? I guess that doesn't make sense, because you can't anticipate the fees until the CFD is closed. How would you handle those TX fees?

Funding fees should be displayed as an accumulated value with a + and -, + meaning you are earning from this CFD and - meaning you are paying.

I like that we can separate the funding fees from all the other ones, since they are a feature of a CFD.

[thomaseizinger]

Lock transaction fee and opening fee should be paid out of the wallet and not the margin, ie we should lock up margin + expected miner fee + opening fee

With expected miner fee, are you already covering possible collab_close or commit + CET? I guess that doesn't make sense, because you can't anticipate the fees until the CFD is closed. How would you handle those TX fees?

I wouldn't because that would require a separate accounting again.

[luckysori]

So the user wouldn't know about those transaction fees until the CFD is closed? I suppose we could inform them about them on the UI when they're about to close manually.

[thomaseizinger]

Yeah. I think if we make it clear, which actions trigger on-chain transactions, any Bitcoin user will understand that there are fees involved with doing that.

[rishflab]

Agree that the fee breakdown should be shown. IMO the total fees should be prominent and the breakdown shown underneath in a smaller font.