taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Exchange Fee Structure (was: Taler Android UX)


From: Florian Dold
Subject: Re: [Taler] Exchange Fee Structure (was: Taler Android UX)
Date: Tue, 14 Apr 2020 22:44:17 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

We've started to discuss some "denomination structure metrics" in a call
today.

Eventually we have to break down fees (and other properties) into a very
small set of easy to understand numbers.  What these are is not entirely
agreed upon yet ;-)

I'm actually in the process of writing a design doc that lays out the
assumptions/requirement and some possible fee metrics.  But basically,
the user-visible result will be something *similar* to:

"""
The exchange foo.taler.net handles payments in the range of $R1 to $R2.

During normal usage, fees range between ${P1}% and ${P2}%.  Merchants
can cover ${PM1}% to ${$PM2}% of these fees.

Your wallet must be online at least every $X years, otherwise your
digital cash might be lost.

On average, keeping digital cash in your wallet incurs a fee of ${PU}%
per month.
"""

The range of payments is based on the smallest denominations and biggest
denominations the exchange offers.  (The lower range will be a
*multiple* of the lowest denomination offered, otherwise we run into the
problem of not being able to obtain change and having to throw away the
remaining value.)

We're not sure yet on quite a lot of these details, since fees can vary
with (1) which coins you currently have in your wallet, (2) the amount
you're paying and (3) how much the merchant is willing to cover.  Also,
what should we show?  A spark graph?  Only the average?  Lower, upper
bound and mean?

But it should certainly be our goal to be able to break it down to
easy-to-understand numbers.  We still might want to be able to view the
details, but not by default.

Why is this difficult?  Because we don't want to completely fix the fee
structure, as some operational / legal concerns that lead to determine
fees are not yet known and might change from deployment to deployment.

There are some things even more difficult to determine, such as "how
good is the fee structure for privacy", as this depends on the number of
customers the exchange has.

- Florian

On 4/14/20 10:18 PM, Torsten Grote wrote:
> On 2020-04-13 16:56, Christian Grothoff wrote:
>>> I guess it would need a lot of malicious consumers to achieve that
>>> and imagine that one could put other defenses against that in
>>> place.
>> Tricky, due to customer's anonymity you don't really have any good
>> way to do accounting, and no good way to tell legitimate from
>> illegitimate requests. And of course we cannot simply NOT answer
>> requests either.
> 
> I don't know yet how refreshing exactly works, but could there be a
> refresh counter for coins high enough to allow legitimate use, but low
> enough to prevent abuse?
> 
>> Well, it's of course more difficult ;-). Merchants can specify that
>> they are willing to pay certain "reasonable" wire fees. [...] But
>> imagine an exchange charges 1 EUR for wire transfers. [...] Here, the
>> merchant additionally specifies an amortization factor (a factor of
>> 40 means that the 80 cents are to be amortized over 40 customers).
>> Then, each customer would have to contribute 2 cents in wire fees.
>> But possibly not exactly 2 cents, if there is room from the deposit
>> fees...
> 
> Uff. Complicated indeed. Would be much easier without wire fees, but I
> guess you have considered that and it would run contrary to some other
> design goal.
> 
> So as a user withdrawing money, I would want to be careful with
> exchanges charging high wire fees, because that *might* increase my fee
> with a merchant I want to pay.
> 
> Maybe when showing the fees, we could hide wire fees and closing fees
> for future years when the price only increases moderately with an option
> to expand the full details.
> 
> But really, from a consumer and UX perspective, exchanges that charge
> for more than withdrawal (and maybe refresh/change) operations introduce
> so much complexity that I have a hard time imagining this being used in
> practice, especially when you compare it with the simplicity these new
> fintech apps offer. Worse: The additional complexity can be used to
> screw users over by hiding high fees in there.
> 
> So I'd say the wallet should warn about all exchanges making use of the
> fee complexity that Taler supports until there is evidence from
> practical use that the complexity is actually needed.
> 
>>> Interesting. Should we maybe have little info buttons next to the
>>> fee labels with these explanations?
>> Yes. Little info buttons, but then likely jumping to walls of text
>> with the explanations ;-(.
> 
> If you want to support the full complexity and require users to
> understand it, I see no way around providing walls of text. But at least
> they are hidden by default and need to be actively opened.
> 
> Kind Regards,
> Torsten
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]