008-fees.rst (4992B)
1 XX 08: Fee Structure Metrics 2 ############################ 3 4 .. note:: 5 6 This design document is deprecated. 7 8 9 Summary 10 ======= 11 12 We discuss criteria for evaluating an exchange's denomination and fee structure. 13 14 Motivation 15 ========== 16 17 Currently, users of a Taler wallet can't easily judge the fee structure of an 18 exchange and what it will mean for them. Thus we want to define some metrics 19 that allow a user to make more informed decisions. 20 21 Similarly, the fee structure metrics might be used by exchange operators 22 as a sanity check. 23 24 An auditor might also enforce ranges on these metrics as a condition for 25 auditing a denomination structure. 26 27 Requirements 28 ============ 29 30 * Privacy: A denomination structure that has too many denominations 31 will result in reduced anonymity. 32 * Efficiency: A denomination structure that has too few denominations 33 is inefficient. 34 * Predictability: 35 36 * The amount of fees for an operation should not come 37 as a total surprise for the user. 38 39 * The user should know beforehand when they have to be online 40 to refresh their balance, and they should know how much 41 this will cost them. 42 43 The metrics for the exchange should be advisory, i.e. an informed user should 44 be able to accept the withdrawal anyway. 45 46 The exchange's business interests may be in conflict with (1) a transparency of 47 cost for the user and and (2) restrictions on denomination/fee structures. 48 Thus the metrics should still allow some degree of variability between 49 exchanges. 50 51 We make the assumption that wallet always prefer operations with better 52 privacy. For example, a single coin should only be used for at most one 53 spend operation and at most one refresh operation. 54 55 Proposed Solution 56 ================= 57 58 The following yes/no criteria are applied to determine if a denomination/fee structure 59 is *reasonable*: 60 61 * For a denomination of value ``v``, either 62 63 (a) ``v`` must be the smallest offered denomination, or 64 (b) there must be another denomination with a value of at least ``v / 10``. 65 66 Is there a relationship between the smallest denomination and the size of fees? 67 68 Idea: When when only doing spends on a coin that are a multiple of the smallest spending amount, 69 we constrain the number of coins that are refreshed into. 70 71 When evaluating the e2e cost of a denomination, look at: 72 * the cost of withdrawing the coin by itself and spending it fully, directly 73 * the cost of withdrawing the coin, directly refreshing it into the next smallest 74 fully fitting currency (or use greedy fit!) and add up the withdraw, refresh and re-withdraw fees. 75 * percentage is always computed with sum against the full coin's value 76 * smallest coins are an exception 77 78 Actually, smallest spendable amount should be a multiple of the smallest coins, since 79 we still need to deal with fees even at that level 80 81 82 Refund fees should not be higher than if the user got a refund through 83 a different channel than Taler and then purchased the product again. 84 85 86 87 The following metrics are also defined: 88 89 * Shortest time from withdrawal expiration to deposit expiration. 90 * Upkeep, i.e. how much does it cost the customer to keep coins in their wallet 91 per time period, on average over a long period. 92 * Assurance period, i.e. the time span for which the exchange has already announced 93 its fees. 94 * Spending amount range. 95 * End-to-end fee range. This is the minimum/maximum cost to withdraw electronic cash 96 (within the spending range), spend some of it and then obtain change for the transaction. 97 * Merchant contribution range. This is the percentage of the end-to-end fees that the merchant 98 can cover if they choose to do so. 99 100 101 Alternatives 102 ============ 103 104 * Users can manually study the fee structure. 105 * The auditor could impose a fee structure and not 106 allow any variability between exchanges 107 108 Drawbacks 109 ========= 110 111 * The approach does not work well in some special-purpose deployments, 112 where the coin structure is tailored to the products of merchants, 113 and refreshing would never even happen. 114 115 * The approach also does not consider more "creative" fee structures, 116 such as ones where coins that are valid for a longer time have higher 117 fees. 118 119 Discussion / Q&A 120 ================ 121 The Taler protocol offers the following fee types: 122 123 1. **Withdrawal**: For each successful withdrawal from the checking account, **per coin** 124 2. **Deposit**: For spending, **per coin** 125 3. **Refresh**: **Per coin** for 126 a. Refresh transactions for receiving change 127 b. Refresh of coins at the end of their validity 128 c. Abort of transactions due to network failure 129 d. Refund 130 4. **Refund**: For refunds or in case of contract cancellation by seller, **per coin** 131 5. **Wire fee**: For aggregated amounts wired by the Exchange to the merchant's checking account, **per wire transfer** 132 6. **Closing**: In case a withdrawal process could not be accomplished (the user's wallet did not withdraw the value from the reserve), **per wire transfer** from the Exchange's escrow account to the account of origin