summaryrefslogtreecommitdiff
path: root/design-documents/fees.rst
blob: 964594232cf2f86fbcb78f44eaefa03f6ff5f4f4 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
Design Doc 003: Fee Structure Metrics
#####################################

.. note::

  This design document is currently a draft, it
  does not reflect any implementation decisions yet.

Summary
=======

We discuss criterea for evaluating an exchange's denomination and fee structure.

Motivation
==========

Currently, users of a Taler wallet can't easily judge the fee structure of an
exchange and what it will mean for them.  Thus we want to define some metrics
that allow a user to make more informed decisions.

Similarly, the fee structure metrics might be used by exchange operators
as a senity check.

An auditor might also enforce ranges on these metrics as a condition for
auditing a denomination structure.

Requirements
============

* Privacy:  A denomination structure that has too many denominations
  will result in reduced anonymity.
* Efficiency:  A denomination structure that has too few denominations
  is inefficient.
* Predictability:

  * The amount of fees for an operation should not come
    as a total surprise for the user.

  * The user should know beforehand when they have to be online
    to refresh their balance, and they should know how much
    this will cost them.

The metrics for the exchange should be advisory, i.e. an informed user should
be able to accept the withdrawal anyway.
  
The exchange's business interests may be in conflict with (1) a transparency of
cost for the user and and (2) restrictions on denomination/fee structures.
Thus the metrics should still allow some degree of variability between
exchanges.

We make the assumption that wallet always perfer operations with better
privacy.  For example, a single coin should only be used for at most one
spend operation and at most one refresh operation.

Proposed Solution
=================

The following yes/no criteria are applied to determine if a denomination/fee structure
is *reasonable*:

* For a denomination of value ``v``, either

  (a) ``v`` must be the the smallest offered denomination, or 
  (b) there must be another denomination with a value of at least ``v / 10``.

Is there a relationship between the smallest denomination and the size of fees?

Idea: When when only doing spends on a coin that are a multiple of the smallest spending amount,
we constrain the number of coins that are refreshed into.

When evaluating the e2e cost of a denomiation, look at:
 * the cost of withdrawing the coin by itself and spending it fully, directly
 * the cost of withdrawing the coin, directly refreshing it into the next smallest
   fully fitting currency (or use greedy fit!) and add up the withdraw, refresh and re-withdraw fees.
 * percentage is always computed with sum against the full coin's value
 * smallest coins are an exception

Actually, smallest spendable amount should be a multiple of the smallest coins, since
we still need to deal with fees even at that level


Refund fees should not be higher than if the user got a refund through
a different channel than Taler and then purchased the product again.



The following metrics are also defined:

* Shortest time from withdrawal expiration to deposit expiration.
* Upkeep, i.e. how much does it cost the customer to keep coins in their wallet
  per time period, on average over a long period.
* Assurance period, i.e. the time span for which the exchange has already announced
  its fees.
* Spending amount range.
* End-to-end fee range.  This is the minimum/maximum cost to withdraw electronic cash
  (within the spending range), spend some of it and then obtain change for the transaction.
* Merchant contribution range.  This is the percentage of the end-to-end fees that the merchant
  can cover if they choose to do so.


Alternatives
============

* Users can manually study the fee structure.
* The auditor could impose a fee structure and not
  allow any variability between exchanges

Drawbacks
=========

* The approach does not work well in some special-purpose deployments,
  where the coin structure is taylored to the products of merchants,
  and refreshing would never even happen.

* The approach also does not consider more "creative" fee structures,
  such as ones where coins that are valid for a longer time have higher
  fees.

Discussion / Q&A
================