Stablecoin issuer: roll 'technical details' into other pages

content/concepts/payment-types/sending-payments-to-customers.md

@@ -11,14 +11,16 @@ When you build an automated system to send payments into the XRP Ledger for your
 
 Generally, when sending stablecoins, you use a [Payment transaction][]. Some of the details are different depending on whether you are issuing tokens for the first time or transferring them from a hot wallet to a customer. Things to note include:
 
+- Always specify your issuing address as the issuer of the token. Otherwise, you might accidentally use paths that deliver the same currency issued by other addresses.
+- Before sending a payment into the XRP Ledger, double check the cost of the payment. A payment from your operational address to a customer should not cost more than the destination amount plus any transfer fee you have set.
 - When issuing new tokens from your issuing address, you should omit the `SendMax` field. Otherwise, malicious users can arrange their settings so that you issue the full `SendMax` amount instead of just the intended destination `Amount`.
 - When sending tokens _from a hot wallet_, you must specify `SendMax` if you have a nonzero transfer fee. In this case, set the `SendMax` field to the amount specified in the `Amount` field plus the transfer fee. (You may want to round up slightly, in case the precision of your calculations doesn't exactly match the XRP Ledger's.) For example, if you send a transaction whose `Amount` field specifies 99.47 USD, and your transfer fee is 0.25%, you should set the `SendMax` field to 124.3375, or 124.34 USD if you round up.
-- Omit the `Paths` field. This field is unnecessary when sending directly from the issuer, or from a hot wallet as long as the tokens being sent and the tokens being received have the same currency code and issuer—that is, they're the same stablecoin. The `Paths` field is intended for [Cross-Currency Payments](cross-currency-payments.html) and longer multi-hop (rippling) payments. If you naively perform pathfinding and attach the paths to your transaction, your payment may take a more expensive indirect route rather than failing if the direct path is not available; malicious users can even set this up to 
+- Omit the `Paths` field. This field is unnecessary when sending directly from the issuer, or from a hot wallet as long as the tokens being sent and the tokens being received have the same currency code and issuer—that is, they're the same stablecoin. The `Paths` field is intended for [Cross-Currency Payments](cross-currency-payments.html) and longer multi-hop (rippling) payments. If you naively perform pathfinding and attach the paths to your transaction, your payment may take a more expensive indirect route rather than failing if the direct path is not available; malicious users can even set this up to
 - If you get a `tecPATH_DRY` result code, this usually indicates that either the customer doesn't have the necessary trust line set up already, or your issuer's rippling settings aren't configured correctly.
 
 For a detailed tutorial on issuing a token on the XRP Ledger, whether a stablecoin or otherwise, see [Issue a Fungible Token](issue-a-fungible-token.html).
 
 <!--{# common link defs #}-->
-{% include '_snippets/rippled-api-links.md' %}			
-{% include '_snippets/tx-type-links.md' %}			
-{% include '_snippets/rippled_versions.md' %}
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/fungible-tokens/stablecoins/configuration.md

@@ -26,6 +26,8 @@ The Default Ripple flag controls whether the balances on a trust line are allowe
 
 Before asking customers to create trust lines to its issuing address, an issuer should enable the Default Ripple flag on that address. Otherwise, the issuer must individually disable the No Ripple flag for each trust line that other addresses have created.
 
+You should _not_ enable the Default Ripple flag on other addresses, such as your operational or standby wallets.
+
 
 ## Deposit Authorization
 
@@ -41,6 +43,13 @@ Therefore, Deposit Authorization is not recommended for stablecoin issuers unles
 For more information, see [Deposit Authorization](depositauth.html).
 
 
+## Disallow Incoming Trust Line
+
+The Disallow Incoming Trust Line setting prevents other users from opening trust lines to an address. As a precaution, you should enable this setting on your operational and standby addresses so that those addresses cannot issue tokens even inadvertently. Do not enable this setting on your issuing address.
+
+To enable this setting, send an [AccountSet transaction](accountset.html) with `"SetFlag": 15` (`asfDisallowIncomingTrustline`).
+
+
 ## Disallow XRP
 
 The Disallow XRP setting is designed to discourage XRP Ledger users from sending XRP to an address by accident. This reduces the costs and effort of bouncing undesired payments from addresses that aren't intended to receive and hold XRP. The Disallow XRP flag is not enforced at the protocol level, because doing so could allow addresses to become permanently unusable if they run out of XRP. Client applications should honor the Disallow XRP flag by default, but may allow users to ignore it.

content/concepts/tokens/fungible-tokens/stablecoins/precautions.md

@@ -7,17 +7,48 @@ labels:
 ---
 # Stablecoin Precautions
 
-Processing payments to and from the XRP Ledger naturally comes with some risks, so an issuer should be sure to take care in implementing these processes. As a stablecoin issuer, you should consider the following precautions:
-
-- Protect yourself against reversible deposits. XRP Ledger payments are irreversible, but many digital payments are not. Scammers can abuse this to take their fiat money back by canceling a deposit after receiving tokens in the XRP Ledger.
-- When sending into the XRP Ledger, always specify your issuing address as the issuer of the token. Otherwise, you might accidentally use paths that deliver the same currency issued by other addresses.
-- Before sending a payment into the XRP Ledger, double check the cost of the payment. A payment from your operational address to a customer should not cost more than the destination amount plus any transfer fee you have set.
-- Before processing a payment out of the XRP Ledger, make sure you know the customer's identity. This makes it harder for anonymous attackers to scam you. Most anti-money-laundering regulations require this anyway. This is especially important because the users sending money from the XRP Ledger could be different than the ones that initially received the money in the XRP Ledger.
-- Follow the guidelines for reliable transaction submission when sending XRP Ledger transactions.
-- Robustly monitor for incoming payments, and read the correct amount. Don't mistakenly credit someone the full amount if they only sent a [partial payment](partial-payments.html). See [Robustly monitoring for payments](robustly-monitoring-for-payments.html).
+Processing payments to and from the XRP Ledger naturally comes with some risks, so an issuer should be sure to take care in implementing these processes. As a stablecoin issuer, you should consider the following precautions.
+
+
+## Infrastructure
+
+For your own security as well as the stability of the network, each XRP Ledger business should [run its own XRP Ledger servers](install-rippled.html), including one [validator](rippled-server-modes.html#validators).
+
+
+## Tool Security
+
+Any time you submit an XRP Ledger transaction, it must be signed using your secret key. The secret key gives full control over your XRP Ledger address. Never send your secret key to a server run by someone else. Either use your own server, or sign the transactions locally using a client library. For instructions and examples of secure configurations, see [Set Up Secure Signing](secure-signing.html).
+
+There are several interfaces you can use to connect to the XRP Ledger, depending on your needs and your existing software:
+
+- [HTTP / WebSocket APIs](http-websocket-apis.html) can be used as a low-level interface to all core XRP Ledger functionality.
+- [Client Libraries](client-libraries.html) are available in several programming languages to provide convenient utilities for accessing the XRP Ledger.
+- Other tools such as [xApps](https://xumm.readme.io/docs/xapps) are also available.
+- Third party wallet applications might also be useful, especially for humans in charge of standby addresses.
+
+However, take care to only use reputable tools from their official distribution channels. Malicious servers, libraries, or apps could be configured to leak secret keys to an attacker.
+
+
+## Payments from the XRP Ledger
+
+When receiving payments from the XRP Ledger, it's important to recognize when a payment is final or not, and to credit the customer for the correct amount, so that your processes and integration software can't be exploited. For details and common pitfalls, see [Robustly Monitoring for Payments](robustly-monitoring-for-payments.html).
+
+If you receive an unexpected or unwanted payment, the standard practice is to return it to the sender. For details of how to do this without incurring additional costs, see [Bouncing Payments](bouncing-payments.html).
+
+Before processing a payment out of the XRP Ledger, make sure you know the customer's identity. This makes it harder for anonymous attackers to scam you. Most anti-money-laundering regulations require this anyway. This is especially important because the users sending money from the XRP Ledger could be different than the ones that initially received the money in the XRP Ledger. For more context, see [Stablecoin Compliance Guidelines](stablecoin-compliance-guidelines.html).
+
+
+## Payments into the XRP Ledger
+
+When sending payments into the XRP Ledger, follow best practices to avoid overpaying on fees and roundabout paths. For details, see [Sending Payments to Customers](sending-payments-to-customers.html).
+
+If you accept payments from in external systems, such as bank deposits or credit/debit payments, be sure to protect yourself against reversible deposits. XRP Ledger payments are irreversible, but many other digital payments are not. Scammers can abuse this to take their fiat money back by canceling a non-XRPL transaction after you've already sent an XRP Ledger payment.
+
+Additionally, follow the [Reliable Transaction Submission guidelines](reliable-transaction-submission.html) to ensure that you know the final outcome of your XRP Ledger transactions even in rare circumstances like power failures or network outages.
+
+
+## Other precautions
+
 - Track your obligations and balances within the XRP Ledger, and compare with the assets in your collateral account. If they do not match up, stop processing withdrawals and deposits until you resolve the discrepancy.
-- Avoid ambiguous situations. We recommend the following:
-    - Enable the `Disallow XRP` flag for the issuing address and all operational addresses, so customers do not accidentally send you XRP. (Private exchanges should *not* set this flag, since they trade XRP normally.)
-    - Enable the [`RequireDest` flag](require-destination-tags.html) for the issuing address and all operational addresses, so customers do not accidentally send a payment without the destination tag to indicate who should be credited.
-    - Enable the `RequireAuth` flag on all operational addresses so they cannot issue tokens by accident.
-- Monitor for suspicious or abusive behavior. For example, a user could repeatedly send funds into and out of the XRP Ledger, as a denial of service attack that effectively empties an operational address's balance. Suspend customers whose addresses are involved in suspicious behavior by not processing their XRP Ledger payments.
+- Avoid ambiguous situations. Setting up the appropriate settings on all your addresses helps to avoid cases like accidentally issuing tokens from the wrong address or users sending money to the wrong place. For recommendations, see [Stablecoin Configuration](stablecoin-configuration.html).
+- Monitor for suspicious or abusive behavior. For example, a user could repeatedly send funds into and out of the XRP Ledger, as a denial of service attack that effectively empties an operational address's balance. Suspend customers whose addresses are involved in suspicious behavior by not processing their XRP Ledger payments.