DD46: small improvements

1 files changed, 20 insertions, 22 deletions

diff --git a/design-documents/046-mumimo-contracts.rst b/design-documents/046-mumimo-contracts.rst
index 714b5822..41e659dd 100644
--- a/design-documents/046-mumimo-contracts.rst
+++ b/design-documents/046-mumimo-contracts.rst
@@ -68,20 +68,18 @@ Proposed Solution
 
 Merchants will also blindly sign tokens (not coins) to indicate the
 eligibility of a user for certain special offers. Contracts will be modified
-to allow requiring multiple inputs (to be *provisioned*" to the merchant) and
-multiple outputs (to be *yielded* by the merchant).  Contracts will also
-include multiple options for how a user may pay or what they might want to
-purchase. The wallet will then allow the user to select between the choices
-that the user could pay for, or possibly make an automatic choice if the
-correct choice is obvious. One output option is blindly signed coins from
-another exchange, possibly in a different currency. Another output option is
-blindly signed donation receipts from a DONation AUthority (DONAU).
-Subscriptions can be modeled by requiring the wallet to provision a token of
-the same type that is also yielded by the contract. For security, payments
-using subscription tokens (and possibly certain other special tokens?) will be
-limited to a list of domains explicitly defined as trusted by the token
-issuer.  When paying for a contract, the wallet must additionally sign over
-the selected sub-contract index and a hash committing it to the blinded
+to allow requiring multiple inputs (to be *provisioned* to the merchant) and
+multiple outputs (to be *yielded* by the merchant).  The wallet will then allow
+the user to select between the choices that the user could pay for, or possibly
+make an automatic choice if the correct choice is obvious. One output option is
+blindly signed coins from another exchange, possibly in a different currency.
+Another output option is blindly signed donation receipts from a DONation
+AUthority (DONAU). Subscriptions can be modeled by requiring the wallet to
+provision a token of the same type that is also yielded by the contract. For
+security, payments using subscription tokens (and possibly certain other special
+tokens?) will be limited to a list of domains explicitly defined as trusted by
+the token issuer.  When paying for a contract, the wallet must additionally sign
+over the selected sub-contract index and a hash committing it to the blinded
 envelopes (if any).  The merchant backend will (probably?) need to be changed
 to truly support multiple currencies (ugh).
 
@@ -243,8 +241,8 @@ The contract terms v1 will have the following structure:
 .. ts:def:: ContractInput
 
   type ContractInput =
-    ContractInputRation |
-    ContractInputToken;
+    | ContractInputRation
+    | ContractInputToken;
 
 .. ts:def:: ContractInputRation
 
@@ -283,9 +281,9 @@ The contract terms v1 will have the following structure:
 .. ts:def:: ContractOutput
 
   type ContractOutput =
-    ContractOutputCoin |
-    ContractOutputTaxReceipt |
-    ContractOutputToken;
+    | ContractOutputCoin
+    | ContractOutputTaxReceipt
+    | ContractOutputToken;
 
 .. ts:def:: ContractOutputCoin
 
@@ -334,7 +332,7 @@ The contract terms v1 will have the following structure:
 .. ts:def:: TokenClass
 
   type TokenClass =
-    TokenClassSubscription
+    | TokenClassSubscription
     | TokenClassDiscount
 
 .. ts:def:: TokenClassSubscription
@@ -421,8 +419,8 @@ The contract terms v1 will have the following structure:
 .. ts:def:: TokenSignerPublicKey
 
   type TokenSignerPublicKey =
-    DenomGroupRsa |
-    DenomGroupCs;
+    | DenomGroupRsa
+    | DenomGroupCs;
 
 TODO: may want to do a deep copy and rename
 DenomGroup* to TokenSignerPublicKey* here.