path: root/design-documents
diff options
authorStefan Kügel <>2021-02-03 22:12:52 +0100
committerStefan Kügel <>2021-02-03 22:12:52 +0100
commitd29a9f4512937377daa5406789eb610b6d97cfa3 (patch)
tree06a7408f2985bb06d7758b7ce2e5b5cd6b39127e /design-documents
parente4829d273e6108583151d25173a47e348cdfcb48 (diff)
Eliminating some superfluous line breaks, two little bugs
Diffstat (limited to 'design-documents')
1 files changed, 3 insertions, 29 deletions
diff --git a/design-documents/012-fee-schedule-metrics.rst b/design-documents/012-fee-schedule-metrics.rst
index 4a9c8e8..8eb36da 100644
--- a/design-documents/012-fee-schedule-metrics.rst
+++ b/design-documents/012-fee-schedule-metrics.rst
@@ -13,7 +13,6 @@ structure of an Exchange from different points of view (Exchange operators,
buyers/users, and sellers/merchants).
@@ -60,7 +59,7 @@ The protocol does not allow retroactive changes for denomination keys that
have already been announced. This protects buyers against fee hikes for
coins they already withdrew. Additionally, the **wire** and **closing** fees
that apply per wire transfer must be configured for each wire method. These
-fees are typcially defined per calendar year.
+fees are typically defined per calendar year.
For deposit, withdraw, refresh and refund operations, fees are charged per
coin. The number of coins per operation increases logarithmically with the
@@ -129,7 +128,7 @@ conflicting criteria:
run transactions to increase transaction costs at the Exchange or
to impact availability for normal users. The most effective operation
for such attacks are refresh operations, especially if those do not have a fee.
-* From a marketing perspective, it is unwise if buyers see fees.
+* From a marketing perspective, it is unwise that buyers see fees.
In particular, **withdraw** fees are likely to be the biggest deterrent
as they appear before the buyer actually uses the system to make a payment.
Only **deposit** and **wire** fees can be made "invisible" to buyers
@@ -184,7 +183,6 @@ exchange differs:
the Exchange operators or sellers. Nevertheless, the Exchange operator
could introduce a **closing** fee to cover such costs.
We now consider each of the fee types, viewed from the perspective of the
buyer, the Exchange operator, and the seller, in detail.
@@ -210,7 +208,6 @@ bandwidth demands as well as **refresh** fees. Thus, there does not seem to be
a need to provide an additional incentive in the form of **withdraw** fees
**Withdraw** fee for the Exchange operator
@@ -223,7 +220,6 @@ fees, consumers may choose to hoard digital cash, which may create a
legal and (negative) interest liability for the operator. Introducing
a **withdraw** fee may help an Exchange operator collect revenue up-front.
**Withdraw** fee for sellers
@@ -232,11 +228,9 @@ a psychological barrier for their buyers to use Taler. Sellers may thus
prefer to include the costs of generating coins in their selling prices and
hide this cost from buyers.
**Deposit** fee for buyers
**Deposit** fees are split between buyer and seller, the seller offering to
cover a certain total amount in fees (as part of the commercial offer) and
the buyer having to cover the remaining amount in full. It is expected that
@@ -247,7 +241,6 @@ for buyers if they choose an expensive Exchange operator.
Deposit fees are thus a good candidate to cover all or most expenses that
Exchange operators have to bear.
**Deposit** fee for Exchange operators
@@ -260,20 +253,18 @@ wire transfers to happen rarely (like once per year). Thus, an Exchange
operator that wants regular income from regular users must charge either
**deposit** or **withdraw** fees.
**Deposit** fee for sellers
As an Exchange operator could charge high **deposit** fees, sellers can
protect themselves against excessive fees by refusing to cover fees. Sellers
-determine the default maximum amount want to bear by setting the variable
+determine the default maximum amount they want to bear by setting the variable
``default_max_deposit_fee``. This default can be overridden on a per-purchase
basis. **Deposit** fees exceeding this maximum are borne by the buyer.
Sellers are expected to cover **deposit** fees to a similar degree that they
cover such expenses with other payment systems.
**Refresh** fee for buyers
@@ -297,7 +288,6 @@ about negative interest rates. We expect that they will often not understand
when or why it is charged, especially since fees for getting change are very
uncommon in other payment systems.
**Refresh** fee for Exchange operators
@@ -307,13 +297,11 @@ or to cover these costs with another type of fee. Using the **refresh** fee to
cover costs means that the originators of excessive refreshes requests also
bear their excessive cost.
**Refresh** fee for sellers
Refresh operations do not directly affect sellers.
**Refund** fee for buyers
@@ -332,8 +320,6 @@ Given that buyers would likely perceive it as unfair if they have to pay the
**refund** fee, we generally recommend that Exchange operators should simply
avoid using **refund** fees.
**Refund** fee for Exchange operators
@@ -352,7 +338,6 @@ abuse would have to happen to a degree that can basically be categorized as a
denial-of-service attack, giving the exchange operator a legal argument for
refusing to continue to do business with the abusive seller.
**Refund** fee for sellers
@@ -369,8 +354,6 @@ when charging **refund** fees, as this may create probems for retailers that
are legally obliged to refund 100% of the buyer's expenses (including banking
**Wire** fee for buyers
@@ -387,8 +370,6 @@ charge competitive rates, and sellers are likely to be happy to cover the
entire **wire** fee. Thus, **wire** fees should in practice rarely matter
for buyers.
**Wire** fee for Exchange operators
@@ -411,8 +392,6 @@ as they need it for their business and want to afford the fee for it. Thus,
setting **wire** fees slightly above operational costs for wire transfers
should result in an optimal wire transfer frequency.
**Wire** fee for sellers
@@ -424,7 +403,6 @@ costs due to the **wire** fee or forego liquidity. However, as **wire** fees
are expected to be relatively low, sellers are likely to primarily set their
aggregation periods based on the needs for refunds.
**Closing** fee for buyers
@@ -441,7 +419,6 @@ to depend on income from such a fee, and not having a **closing** fee will
simplify the terms of service and could be a cheap way to produce or maintain
consumer goodwill.
**Closing** fee for Exchange operators
@@ -456,7 +433,6 @@ not be a problem: malicious parties wiring funds to the Exchange to trigger
**closing** operations would need to have spare liquidiy, would still have to
cover their own banking costs, and would also be easily identified.
**Closing** fee for sellers
@@ -466,7 +442,6 @@ The **closing** fee does not affect sellers in any way.
Proposed Solution
Fee levels if abuse is low
@@ -500,7 +475,6 @@ This fee structure becomes problematic if attackers begin to abuse it, say by
excessively refreshing coins or constantly depositing and refunding the same
Fee levels in case of abuse