paychan use case: rome's feedback

content/use-cases/open-a-payment-channel-to-enable-an-inter-exchange-network.md

@@ -12,16 +12,12 @@ The need to send XRP from your exchange to another exchange may originate with y
 
 ## Benefits of Using a Payment Channel
 
-Here are some of the benefits of using a payment channel to send XRP instead of using individual payment transactions:
+Here are some of the benefits of using a payment channel to send XRP instead of using individual payment transactions: <!-- {# TODO: for the future, complete https://ripplelabs.atlassian.net/browse/DOC-2243 to see if using a payment channel would actually result in a cost benefit to the sending exchange #}-->
 
 - **Process withdrawals faster:** A standard payment transaction involves submitting an XRP Ledger transaction and waiting for a new ledger version that includes the transaction to be approved by [consensus](consensus.html). When you use a payment channel to send XRP, creation and verification of a claim, which guarantees the payment of XRP, all happen outside of the consensus process. This means that the payer exchange can guarantee XRP payments to the payee exchange at a rate limited only by the participants' ability to create and verify the digital signatures of the claims.
 
       For your customers who are moving XRP to take advantage of arbitrage opportunities or to do algorithmic trading, speed matters. Enabling a customer to move XRP and start trading in an instant is a compelling differentiator for your exchange.
 
-- **Lower transaction costs:** The payee exchange can choose to take the claims it has received from the payer exchange and redeem them in batches to receive the guaranteed XRP amounts. Redeeming a batch of claims in a single transaction incurs a _single_ transaction cost, while processing multiple XRP payment transactions (one per claim without a payment channel in place, for example) to receive the same amount of XRP incurs _multiple_ transaction costs.
-
-      For example, instead of processing 10,000 XRP payment transactions, you can process the same payments in 5-10 batches of payment channel claims instead. Depending on volume, the savings in transaction costs can be meaningful over time.
-
 - **Connect to the Internet of Value:** One of the key requirements of the [Internet of Value](https://ripple.com/insights/the-internet-of-value-what-it-means-and-how-it-benefits-everyone/) is interoperability. The [Interledger Protocol](https://interledger.org/) (ILP), which plays a large role in driving this interoperability, works best when it [uses payment channels](https://interledger.org/rfcs/0027-interledger-protocol-4) as its method for rebalancing accounts. In effect, when you open a payment channel from your exchange to another, you are connecting to the Internet of Value and helping to create the inter-exchange network that is fundamental to the success of the Internet of Value and the apps that are built on it.
 
       Connecting your exchange to other exchanges by way of payment channels is another differentiator. For customers who are moving XRP to purchase various currencies across exchanges, knowing that they can move XRP at a moment's notice from your exchange to any number of exchanges in the Internet of Value can make your exchange a preferred place to custody their assets.
@@ -55,15 +51,19 @@ If not, a great way for an exchange to get access to a `rippled` server is to se
 
 If your exchange processes XRP deposits and withdrawals directly, you probably have existing funded XRP Ledger accounts that you can use for this purpose. Just ensure that they are funded with enough XRP as described here.
 
-Along these lines, there's a good chance that you are following industry best practices and have a cold account plus one or more hot accounts. Also according to best practices, you probably want to use hot accounts for your payment channels.
+Along these lines, there's a good chance that you are following industry best practices and have a cold account plus one or more hot accounts. Use the hot accounts for your payment channels.
 
 - The payer exchange must have a funded XRP Ledger account to be used to send XRP to the payee exchange.
 
       Aside from the [base reserve](reserves.html) (20 XRP) and the [owner reserve](reserves.html#owner-reserves) of a payment channel (5 XRP), the account must also be able to set aside enough XRP in the payment channel to cover the intended number of transactions.
 
-      The payer exchange can always top-off the channel using the [PaymentChannelFund](paymentchannelfund.html) transaction if it runs out of XRP. However, topping-off requires an actual on-ledger transaction and confirmation, so it could take 4-5 seconds of processing time and ~10 drops of XRP to complete the top-off transaction. The more XRP the payer exchange pre-funds, the less often they need to top-off, so they can save some money by pre-funding more XRP.
+      The payer exchange can always top-off the channel using the [PaymentChannelFund](paymentchannelfund.html) transaction if it runs out of XRP. However, topping-off requires an actual on-ledger transaction and confirmation, so it could take 4-5 seconds of processing time and ~10 drops of XRP to complete the top-off transaction. The more XRP the payer exchange pre-funds, the less often they need to top-off, so they can save some time and money by pre-funding more XRP.
 
-      However, if the payer exchange puts in more XRP than they need, they need to [close the payment channel](use-payment-channels.html#9-when-the-payer-and-payee-are-done-doing-business-the-payer-requests-for-the-channel-to-be-closed) to get the XRP back, which means waiting out the `SettleDelay` time they set for the payment channel and two transactions (a request to close the channel and another request to actually close the channel).
+      However, if the payer exchange puts in more XRP than they need, they need to [close the payment channel](use-payment-channels.html#9-when-the-payer-and-payee-are-done-doing-business-the-payer-requests-for-the-channel-to-be-closed) to get the XRP back. This means waiting out the following events:
+
+      1. Completion of the payer's request to start closing the payment channel.
+      2. Passage of the `SettleDelay` time set for the payment channel.
+      3. Completion of a request to finish closing the payment channel after the `SettleDelay` has passed.
 
 - The payee exchange must have a funded XRP Ledger account to be used to redeem (receive) XRP sent by the payer exchange.
 
@@ -78,15 +78,15 @@ The payer exchange opens a payment channel from their XRP Ledger account to the
 
 For this exchange use case, there is no real need to ever close the channel, so the payer exchange may not want to define a `CancelAfter` (expiration) value. If they ever need to close the channel, they can still do so.
 
-Regarding the amount of XRP the payment channel should hold, the payer exchange should consider the typical best practice of holding the vast majority of XRP across all of their user accounts in a cold wallet, with a small amount of XRP in a hot wallet.
+As the payer exchange, you can think of the payment channel as a special sub-wallet exclusively for a particular destination. Consider estimating how much XRP the payment channel requires similar to how you would estimate a hot wallet's needs. According to [typical best practices](issuing-and-operational-addresses.html), exchanges hold the vast majority of XRP across all of their user accounts in a cold wallet, with a small amount of XRP in a hot wallet.
 
-As the payer exchange, you should decide approximately how often you want to add more XRP to the channel—--for example, daily, every 4 hours, or every 15 minutes—--and estimate the volume of XRP that you send to the payee exchange during that interval. You should fund the payment channel with enough to cover at least that much volume or the largest withdrawal that you want to process without delay, whichever is larger. For example, if you plan to refill the channel every 15 minutes, have an average volume of 50 XRP every 15 minutes, but occasionally send transfers of 10,000 XRP, you should supply the channel with at least 10,000 XRP.
+Along these lines, you should also decide approximately how often you want to add more XRP to the payment channel---for example, daily, every 4 hours, or every 15 minutes---and estimate the volume of XRP that you send to the payee exchange during that interval. You should fund the payment channel with enough to cover at least that much volume or the largest withdrawal that you want to process without delay, whichever is larger. For example, if you plan to refill the channel every 15 minutes, have an average volume of 50 XRP every 15 minutes, but occasionally send transfers of 10,000 XRP, you should supply the channel with at least 10,000 XRP.
 
 For withdrawals that are larger than the amount of XRP you have in the payment channel, you must process them specially. Either you can send large withdrawals as normal XRP payments, skipping the payment channel entirely, or you can first send a transaction to add the full withdrawal amount to the payment channel before creating claims for those. (See below for details on creating claims.)
 
-If the payer exchange has multiple XRP Ledger accounts (one for each hot wallet, for example), they should pick a pair of accounts to have a channel between them, then use only that pair of accounts for anything that needs the channel. To be clear, this use case is about creating a payment channel between the exchanges' XRP Ledger accounts, not between customer accounts.
+If either exchange has multiple hot accounts in the XRP Ledger, the two exchanges should each designate a specific hot account to use with the payment channel between them. Although there are other potentially viable configurations, this use case assumes a configuration with one payment channel connecting two exchanges. This channel can serve all customers sending XRP from the payer exchange to the payee exchange.
 
-Also keep in mind that payment channels are unidirectional. So, let's say that exchange A and exchange B want to move XRP in both directions between their XRP Ledger accounts. Exchange A must open a payment channel from their XRP Ledger account to exchange B's XRP Ledger account, and exchange B must open a payment channel from their XRP Ledger account to exchange A's XRP Ledger account.
+Since payment channels are unidirectional, you need a second channel in the opposite direction to send XRP from the _payee_ exchange to the _payer_ exchange. This second channel does not need to connect the exact same pair of hot accounts, but it is most convenient to do so. With two unidirectional channels, each exchange can use the XRP it redeems from its incoming channel to refill its outgoing channel.
 
 
 
@@ -116,14 +116,14 @@ Consider a series of claims prompted by payer exchange customers withdrawing XRP
 | Sequence | Signature         | Amount | Destination Tag |
 |:---------|:------------------|:-------|:----------------|
 | 1        | 3045022100CE6E... | 2000   | 12345678        |
-| 2        | 304402200C304A... | 3000   | 87654321        |
-| 3        | 30450221009849... | 4000   | 18273645        |
+| 2        | 304402200C304A... | 3000   | 23456781        |
+| 3        | 30450221009849... | 4000   | 34567812        |
 
 | Claim Information   | Purpose                                                |
 |:--------------------|:-------------------------------------------------------|
 | **Channel ID**      | Payment channel the payer exchange used to create the claim. The payee exchange needs this value to verify and redeem the claim. |
 | **Public key**      | Public key the payer exchange used to open the payment channel. The payee exchange needs this value to verify and redeem the claim. |
-| **Sequence**        | A value that indicates the sequence in which the payer exchange created the claims. The payee exchange needs this value to keep track of and redeem claims in the correct order. For example, if the payer exchange did not provide the sequence value and the payee exchange lost track of the second claim above, the payee exchange might incorrectly credit 2000 XRP to destination tag 18273645. If the payer exchange did provide the sequence value, the payee exchange would know that it needs to account for a claim between claim 1 and claim 3. With claim 2 accounted for, the payee exchange could correctly credit 1000 XRP to destination tag 87654321 and 1000 XRP to destination tag 18273645. |
+| **Sequence**        | A value that indicates the sequence in which the payer exchange created the claims. The payee exchange needs this value to keep track of and redeem claims in the correct order. For example, if the payer exchange did not provide the sequence value and the payee exchange lost track of the second claim above, the payee exchange might incorrectly credit 2000 XRP to destination tag 34567812. If the payer exchange did provide the sequence value, the payee exchange would know that it needs to account for a claim between claim 1 and claim 3. With claim 2 accounted for, the payee exchange could correctly credit 1000 XRP to destination tag 23456781 and 1000 XRP to destination tag 34567812. |
 | **Signature**       | Signature of the claim. The payee exchange needs this value to verify and redeem the claim. |
 | **Amount**          | Cumulative amount of the claims created by the payer exchange. The payee exchange needs this value to verify and redeem the claim. For information about how to calculate the actual amount the payee exchange needs to credit the customer, see [Verify claims](#payee-verify-claims). |
 | **Destination Tag** | Destination tag of the customer account on the payee exchange that needs to be credited based on the claim. The payer exchange can get this value from their customer's withdrawal request, which should provide a destination tag for the deposit to the payee exchange. When the payee exchange redeems claims, the XRP is deposited into the payee exchange's XRP Ledger account. The payee exchange can then credit the XRP from the claim to the appropriate customer account based on the destination tag provided. |
@@ -144,8 +144,6 @@ For example, to know how much to credit a customer for a claim amount of 3000, t
 <span class="use-case-step-num">{{n.next()}}</span>
 ## Payee: [Redeem them in batches](use-payment-channels.html#8-when-ready-the-payee-redeems-a-claim-for-the-authorized-amount)
 
-This is usually when the payee provides goods or services to the payer in exchange for the amount of XRP listed in the claims. In this use case, the service provided is for the customer to be credited in the payee exchange's own systems, so the customer can start trading.
-
 The payee exchange can redeem batches of claims after verifying them to receive the XRP guaranteed by the payer exchange. Here are some guidelines the payee exchange can use to decide how often to redeem claims:
 
 - Don't redeem every claim. That's not gaining any benefit from the payment channels.