PayChan docs: link things, clean up some typos/inaccuracies

content/tutorial-paychan.md

@@ -59,7 +59,7 @@ This is a [PaymentChannelCreate transaction][]. As part of this process, the pay
 
 **Tip:** The "settlement delay" does not delay the settlement, which can happen as fast as a ledger version closes (3-5 seconds). The "settlement delay" is a forced delay on closing the channel so that the payee has a chance to finish with settlement.
 
-The following example shows creation of a payment channel by submitting to a local `rippled` server with the JSON-RPC API. The payment channel allocates 100 XRP from the [example payer](#example-values) (rN7n7...) to the [example payee](#example-values) (rf1Bi...) with a settlement delay of 1 day. The public key is the example payer's master public key, in hexadecimal.
+The following example shows creation of a payment channel by [submitting](reference-rippled.html#sign-and-submit-mode) to a local `rippled` server with the JSON-RPC API. The payment channel allocates 100 XRP from the [example payer](#example-values) (rN7n7...) to the [example payee](#example-values) (rf1Bi...) with a settlement delay of 1 day. The public key is the example payer's master public key, in hexadecimal.
 
 Request:
 
@@ -163,11 +163,12 @@ In the response from the JSON-RPC, the payer should look for the following:
 - In the transaction's `meta` field, confirm that the `TransactionResult` is `tesSUCCESS`.
 - Confirm that the response has `"validated":true` to indicate the data comes from a validated ledger. (The result `tesSUCCESS` is only [final](reference-transaction-format.html#finality-of-results) if it appears in a validated ledger version.)
 - In the `AffectedNodes` array of the transaction's `meta` field, look for a `CreatedNode` object with the `LedgerEntryType` of `PayChannel`. The `LedgerIndex` field of the `CreatedNode` object indicates the Channel ID. (In the above example, this is a hex string starting with "5DB0...") The Channel ID is necessary later to sign claims.
+    For more information on the PayChannel ledger object type, see [PayChannel ledger node type](reference-ledger-format.html#paychannel).
 
 
 ## 2. The payee checks specifics of the payment channel.
 
-You can look up payment channels with the `account_channels` API method, using the payer of the channel, as in the following example (using the JSON-RPC API):
+You can look up payment channels with the [`account_channels` API method](reference-rippled.html#account-channels), using the payer of the channel, as in the following example (using the JSON-RPC API):
 
 Request:
 
@@ -222,7 +223,7 @@ The amounts of these claims depends on the specific goods or services the payer
 
 Each claim must be for a cumulative amount. In other words, to purchase two items at 10 XRP each, the first claim should have an amount of 10 XRP and the second claim should have an amount of 20 XRP. The claim can never be more than the total amount of XRP allocated to the channel. (A [PaymentChannelFund][] transaction can increase the total amount of XRP allocated to the channel.)
 
-You can create claims with the `channel_authorize` API method. The following example authorizes 1 XRP from the channel:
+You can create claims with the [`channel_authorize` API method](reference-rippled.html#channel-authorize). The following example authorizes 1 XRP from the channel:
 
 Request:
 
@@ -264,7 +265,7 @@ The payee also needs to know the Public Key associated with the channel, which i
 
 ## 5. The payee verifies the claims.
 
-You can verify claims using the `channel_verify` API method. The payee should confirm that the amount of the claim is equal to or greater than the total price of goods and services provided. (Since the amount is cumulative, this is the total price of all goods and services purchased so far.)
+You can verify claims using the [`channel_verify` API method](reference-rippled.html#channel-verify). The payee should confirm that the amount of the claim is equal to or greater than the total price of goods and services provided. (Since the amount is cumulative, this is the total price of all goods and services purchased so far.)
 
 Example of using `channel_verify` with the JSON-RPC API:
 
@@ -294,7 +295,7 @@ Response:
         }
     }
 
-If the response shows `"signature_verified": true` then the claim's signature is genuine. The payee must **also** confirm that the channel has enough XRP available to honor the claim. To do this, the payee makes an `account_channels` request to confirm the most recent validated state of the payment channel.
+If the response shows `"signature_verified": true` then the claim's signature is genuine. The payee must **also** confirm that the channel has enough XRP available to honor the claim. To do this, the payee makes an [`account_channels` request](reference-rippled.html#account-channels) to confirm the most recent validated state of the payment channel.
 
 Request:
 
@@ -340,7 +341,7 @@ The payee should check the following:
 - Confirm that the `balance` of the channel matches the amount the payee expects to have already received from the channel. If these do not match up, the payee should double-check the channel's transaction history. Some possible explanations for a mismatch include:
     - The payer used a [PaymentChannelClaim][] transaction to deliver XRP from the channel to the payee, but the payee did not notice and record the incoming transaction.
     - The payee's records include transactions that are "in flight" or have not yet been included in the latest validated ledger version. The payee can use the [`tx` command](reference-rippled.html#tx) to look up the state of individual transactions to check this.
-    - The `account_channels` request did not specify the correct ledger version. (Use `"ledger_index": "validated"` to get the latest validated leger version)
+    - The `account_channels` request did not specify the correct ledger version. (Use `"ledger_index": "validated"` to get the latest validated ledger version)
     - The payee previously redeemed XRP but forgot to record it.
     - The payee attempted to redeem XRP and recorded the tentative result, but the transaction's final validated result was not the same and the payee neglected to record the final validated result.
     - The `rippled` server the payee queried has lost sync with the rest of the network or is experiencing an unknown bug. Use the [`server_info` command](reference-rippled.html#server-info) to check the state of the server. (If you can reproduce this situation, please [report an issue](https://github.com/ripple/rippled/issues/).)
@@ -361,7 +362,7 @@ The payer and payee can repeat steps 3 through 6 (creating, transmitting, and ve
 
 - The amount of XRP in the payment channel. (If necessary, the payer can send a [PaymentChannelFund transaction][] to increase the total amount of XRP available to the channel.)
 
-- The immutable expiration of the payment channel, if one is set. (The `cancel_after` field in the `account_channels` response shows this.)
+- The immutable expiration of the payment channel, if one is set. (The `cancel_after` field in the [`account_channels`](reference-rippled.html#account-channels) response shows this.)
 
 
 ## 8. When ready, the payee redeems a claim for the authorized amount.
@@ -437,7 +438,7 @@ If the channel _does_ have XRP remaining, the request to close a channel acts as
 
 The payee can also close a payment channel immediately after processing a claim _(9b in the [flow diagram][])_.
 
-Example of submitting a transaction requesting a channel to close:
+Example of [submitting a transaction](reference-rippled.html#sign-and-submit-mode) requesting a channel to close:
 
     {
         "method": "submit",
@@ -453,7 +454,7 @@ Example of submitting a transaction requesting a channel to close:
         }]
     }
 
-After the transaction is included in a validated ledger, either party can look up the currently-scheduled expiration of the channel using the `account_channels` method. Be sure to specify `"ledger_index": "validated"` to get data from the latest validated ledger version.
+After the transaction is included in a validated ledger, either party can look up the currently-scheduled expiration of the channel using the [`account_channels` method](reference-rippled.html#account-channels). Be sure to specify `"ledger_index": "validated"` to get data from the latest validated ledger version.
 
 Example `account_channels` response:
 
@@ -490,7 +491,7 @@ Ripple recommends that the payer sends a second [PaymentChannelClaim transaction
 
 The command to submit the transaction is identical to the previous example requesting channel expiration. (However, its resulting [auto-filled](reference-transaction-format.html#auto-fillable-fields) `Sequence` number, signature, and identifying hash are unique.)
 
-Example of submitting a transaction to close an expired channel:
+Example of [submitting](reference-rippled.html#sign-and-submit-mode) a transaction to close an expired channel:
 
     {
         "method": "submit",
@@ -508,7 +509,7 @@ Example of submitting a transaction to close an expired channel:
 
 When the transaction has been included in a validated ledger, you can look at the metadata of the transaction to confirm that it deleted the channel and returned the XRP to the sender.
 
-Example response from using the `tx` command to look up the transaction from this step:
+Example response from using the [`tx` command](reference-rippled.html#tx) to look up the transaction from this step:
 
     {
         "result": {