From f616af3a9a567cf1d45a3e32a16e2b6e02014e7b Mon Sep 17 00:00:00 2001
From: mDuo13 <mduo13@gmail.com>
Date: Mon, 22 Jul 2019 17:15:42 -0700
Subject: [PATCH 1/8] More interlinking from concept articles

Information architecture improvements, mostly 'See Also' headers within
a bunch of concept articles
---
 content/concepts/introduction/technical-faq.md  | 10 +++++++---
 .../introduction/xrp-ledger-overview.md         |  2 +-
 content/concepts/introduction/xrp.md            |  6 ++++++
 .../payment-system-basics/accounts/accounts.md  | 17 +++++++++++++++++
 .../accounts/multi-signing.md                   | 13 ++++++++++++-
 .../payment-system-basics/accounts/reserves.md  |  7 +++++++
 .../payment-types/cross-currency-payments.md    |  7 +++++++
 7 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/content/concepts/introduction/technical-faq.md b/content/concepts/introduction/technical-faq.md
index 6f1f43b5bf..3238eb44b3 100644
--- a/content/concepts/introduction/technical-faq.md
+++ b/content/concepts/introduction/technical-faq.md
@@ -32,7 +32,9 @@ No. The XRP Ledger network is opt-in. Each participant directly or indirectly ch
 
 #### What is the validator incentive structure for validators not run by Ripple?
 
-If the XRP Ledger becomes successful and is widely used for interbank settlement, there will be an incentive for participants to ensure the reliability and stability of the network. If this happens, institutions will run `rippled` servers to participate in the network. Once you are running a server, the additional cost and effort to operate a validator is essentially zero—it would simply involve flipping a software switch from off to on. It is the validators who decide the evolution of the XRP Ledger, so the primary incentive to run a validator is to preserve and protect the stable operation and sensible evolution of the network.
+The primary incentive to run a validator is to preserve and protect the stable operation and sensible evolution of the network. It is the validators who decide the evolution of the XRP Ledger, so any business that uses or depends on the XRP Ledger has an inherent incentive to ensure the reliability and stability of the network.
+
+If you run an XRP Ledger server to participate in the network, the additional cost and effort to operate a validator is minimal. This means that additional incentives, such as the mining rewards in Bitcoin, are not necessary. Ripple avoids paying XRP as a reward for operating a validator so that such incentives do not warp the behavior of validators.
 
 
 #### Can financial institutions set up transaction validators that will help them meet specific institutional standards and requirements?
@@ -51,7 +53,9 @@ However, there will only be one authoritative ledger version at any given time;
 
 #### Does the XRP Ledger utilize a formal validator onboarding process?
 
-No, a formal validator onboarding process is not compatible with the XRP Ledger, as it is a system with no central authority. Rather, Ripple provides recommendations and best practices.
+No, a formal validator onboarding process is not compatible with the XRP Ledger, as it is a system with no central authority.
+
+For recommendations and best practices, see [Run `rippled` as a Validator](run-rippled-as-a-validator.html).
 
 
 ## Role of XRP
@@ -91,7 +95,7 @@ You don't need to use Ripple’s version of the XRP Ledger software to interact
 
 #### Does Ripple offer a secure method to download their software?
 
-`rippled` source code is available at <https://github.com/ripple/rippled>, where the tip of the `master`, `release` and `develop` branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers prebuilt RPM packages for CentOS, RedHat Enterprise Linux, Fedora and Ubuntu. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the md5sum of the RPM packages that are published.
+`rippled` source code is available at <https://github.com/ripple/rippled>, where the tip of the `master`, `release` and `develop` branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers prebuilt binary packages for CentOS, RedHat Enterprise Linux, Fedora, Ubuntu, and Debian Linux. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the cryptographic hash values of the packages that are published.
 
 
 #### Does Ripple distinguish between the codebase for validation and the one for user software?
diff --git a/content/concepts/introduction/xrp-ledger-overview.md b/content/concepts/introduction/xrp-ledger-overview.md
index a5dedb5a77..7c93ec3a8a 100644
--- a/content/concepts/introduction/xrp-ledger-overview.md
+++ b/content/concepts/introduction/xrp-ledger-overview.md
@@ -79,7 +79,7 @@ For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Mul
 ## Modern Features for Smart Contracts
 [Modern Features for Smart Contracts]: #modern-features-for-smart-contracts
 
-Besides simple value transfer with XRP payments, the XRP Ledger has several advanced features that provide useful functions for building applications that use the Internet of Value to serve previously unknown or impractical needs. Rather than running applications as "smart contracts" in the network itself, the XRP Ledger provides tools for settling contracts, while letting the applications themselves run anywhere, in whatever environment or container is appropriate. This "keep it simple" approach is flexible, scalable, and powerful.
+Besides simple value transfer with [XRP payments](direct-xrp-payments.html), the XRP Ledger has advanced features specialized for the Internet of Value. This allows applications built on XRP to provide services and functionality that would have been impractical or impossible in the past. Rather than running applications as "smart contracts" in the network itself, the XRP Ledger provides tools for settling contracts, while letting the applications themselves run anywhere, in whatever environment or container is appropriate. This "keep it simple" approach is flexible, scalable, and powerful.
 
 A sample of advanced features in the XRP Ledger:
 
diff --git a/content/concepts/introduction/xrp.md b/content/concepts/introduction/xrp.md
index 108eeeef3b..1d680e2083 100644
--- a/content/concepts/introduction/xrp.md
+++ b/content/concepts/introduction/xrp.md
@@ -31,3 +31,9 @@ Originally, the XRP Ledger was called "Ripple" for the way the technology allowe
 
 
 The smallest, indivisible unit of XRP was named a "drop" [at the suggestion of Ripple forum member ThePiachu](https://forum.ripple.com/viewtopic.php?f=1&t=40&p=228). An early alternative term was a "jed", after Jed McCaleb.
+
+## See Also
+
+- [Send XRP (Interactive Tutorial)](send-xrp.html)
+- [List XRP In Your Exchange](list-xrp-in-your-exchange.html)
+- [Currency Formatting in rippled APIs](currency-formats.html#)
diff --git a/content/concepts/payment-system-basics/accounts/accounts.md b/content/concepts/payment-system-basics/accounts/accounts.md
index e48bb86311..48b3046c40 100644
--- a/content/concepts/payment-system-basics/accounts/accounts.md
+++ b/content/concepts/payment-system-basics/accounts/accounts.md
@@ -137,6 +137,23 @@ The formula for calculating an XRP Ledger address is as follows. For the complet
         console.log(address);
         // rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
 
+
+## See Also
+
+- **Concepts:**
+    - [Reserves](reserves.html)
+    - [Cryptographic Keys](cryptographic-keys.html)
+    - [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
+- **References:**
+    - [account_info method][]
+    - [wallet_propose method][]
+    - [AccountSet transaction][]
+    - [Payment transaction][]
+    - [AccountRoot object](accountroot.html)
+- **Tutorials:**
+    - [Manage Account Settings (Category)](manage-account-settings.html)
+    - [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
 {% include '_snippets/tx-type-links.md' %}			
diff --git a/content/concepts/payment-system-basics/accounts/multi-signing.md b/content/concepts/payment-system-basics/accounts/multi-signing.md
index a40ebaf153..659936179b 100644
--- a/content/concepts/payment-system-basics/accounts/multi-signing.md
+++ b/content/concepts/payment-system-basics/accounts/multi-signing.md
@@ -28,8 +28,19 @@ To successfully submit a multi-signed transaction, you must do all of the follow
 * All fields of the transaction must be defined before collecting signatures. You cannot [auto-fill](transaction-common-fields.html#auto-fillable-fields) any fields.
 * If presented in binary form, the `Signers` array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the [submit_multisigned method][] handles this automatically.)
 
-For more information, see [Set Up Multi-Signing](set-up-multi-signing.html).
+## See Also
 
+- **Tutorials:**
+    - [Set Up Multi-Signing](set-up-multi-signing.html)
+    - [Send a Multi-Signed Transaction](send-a-multi-signed-transaction.html)
+- **Concepts:**
+    - [Cryptographic Keys](cryptographic-keys.html)
+    - [Special Transaction Cost for Multi-signed transactions](transaction-cost.html#special-transaction-costs)
+- **References:**
+    - [SignerListSet transaction][]
+    - [SignerList object](signerlist.html)
+    - [sign_for method][]
+    - [submit_multisigned method][]
 
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
diff --git a/content/concepts/payment-system-basics/accounts/reserves.md b/content/concepts/payment-system-basics/accounts/reserves.md
index 823fae35ff..e7f6968841 100644
--- a/content/concepts/payment-system-basics/accounts/reserves.md
+++ b/content/concepts/payment-system-basics/accounts/reserves.md
@@ -46,6 +46,13 @@ When an address holds less XRP than its current reserve requirement, it cannot s
 
 The XRP Ledger has a mechanism to adjust the reserve requirements for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](fee-voting.html) for more information.
 
+## See Also
+
+- [account_objects method][]
+- [AccountRoot Object][]
+- [Fee Voting](fee-voting.html)
+- [SetFee pseudo-transaction][]
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
diff --git a/content/concepts/payment-types/cross-currency-payments.md b/content/concepts/payment-types/cross-currency-payments.md
index 9156acc71c..c641044112 100644
--- a/content/concepts/payment-types/cross-currency-payments.md
+++ b/content/concepts/payment-types/cross-currency-payments.md
@@ -19,6 +19,13 @@ Cross-currency payments that exchange two issued currencies automatically use XR
 
 For more information, see [Autobridging](autobridging.html).
 
+## See Also
+
+- [Issued Currencies](issued-currencies.html)
+- [Decentralized Exchange](decentralized-exchange.html)
+- [Payment transaction type][Payment transaction]
+- [Paths](paths.html)
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
 {% include '_snippets/tx-type-links.md' %}			

From b7777d3f3717fc80092bca96110da2375b17c658 Mon Sep 17 00:00:00 2001
From: mDuo13 <mduo13@gmail.com>
Date: Tue, 23 Jul 2019 16:00:40 -0700
Subject: [PATCH 2/8] More 'See Also' sections

---
 .../concepts/consensus-network/consensus.md   | 21 ++++++++++++++-----
 .../authorized-trust-lines.md                 | 16 ++++++++++++++
 content/concepts/issued-currencies/freezes.md | 11 ++++++++--
 .../issuing-and-operational-addresses.md      | 14 +++++++++++++
 content/concepts/issued-currencies/paths.md   | 13 ++++++++++++
 .../concepts/issued-currencies/rippling.md    | 17 ++++++++++++++-
 .../issued-currencies/transfer-fees.md        | 16 ++++++++++++++
 .../trust-lines-and-issuing.md                | 13 ++++++++++++
 content/concepts/payment-types/checks.md      |  2 +-
 .../payment-types/complex-payment-types.md    |  3 ---
 .../payment-types/cross-currency-payments.md  | 13 ++++++++----
 .../payment-types/direct-xrp-payments.md      | 13 ++++++++----
 content/concepts/payment-types/escrow.md      |  2 +-
 .../payment-types/payment-channels.md         | 14 +++++++++++--
 14 files changed, 145 insertions(+), 23 deletions(-)
 delete mode 100644 content/concepts/payment-types/complex-payment-types.md

diff --git a/content/concepts/consensus-network/consensus.md b/content/concepts/consensus-network/consensus.md
index 98262767b3..31029d76a4 100644
--- a/content/concepts/consensus-network/consensus.md
+++ b/content/concepts/consensus-network/consensus.md
@@ -161,12 +161,23 @@ Best practices for applications submitting transactions include:
         - Take care to use a server with a continuous ledger history to detect this case <a href="#footnote_10" id="from_footnote_10"><sup>10</sup></a>.
     - It may be necessary to check the status of a transaction repeatedly until the ledger identified by `LastLedgerSequence` is validated.
 
-## Further Resources
+## See Also
+
+- **Concepts:**
+    - [Introduction to Consensus](intro-to-consensus.html)
+    - [Consensus Research](consensus-research.html)
+    - [Ripple Consensus Video](https://www.youtube.com/watch?v=pj1QVb1vlC0)
+- **Tutorials:**
+    - [Reliable Transaction Submission](reliable-transaction-submission.html)
+    - [Run `rippled` as a Validator](run-rippled-as-a-validator.html)
+- **References:**
+    - [Ledger Format Reference](ledger-data-formats.html)
+    - [Transaction Format Reference](transaction-formats.html)
+    - [consensus_info method][]
+    - [validator_list_sites method][]
+    - [validators method][]
+
 
-- [Consensus White Paper](https://ripple.com/files/ripple_consensus_whitepaper.pdf)
-- [Ledger Format Reference](ledger-data-formats.html)
-- [Ripple Consensus Video](https://www.youtube.com/watch?v=pj1QVb1vlC0)
-- [Reliable Transaction Submission](reliable-transaction-submission.html)
 
 
 
diff --git a/content/concepts/issued-currencies/authorized-trust-lines.md b/content/concepts/issued-currencies/authorized-trust-lines.md
index f2cda7f695..5df7c27669 100644
--- a/content/concepts/issued-currencies/authorized-trust-lines.md
+++ b/content/concepts/issued-currencies/authorized-trust-lines.md
@@ -98,6 +98,22 @@ To see whether a trust line has been authorized, use the [account_lines method][
 
 In the response's `result.lines` array, find the object whose `currency` field indicates that it represents a trust line for the currency you want. If that object has a `peer_authorized` field with the value `true`, then the issuer (the address you used as the request's `peer` field) has authorized the trust line.
 
+
+## See Also
+
+- **Concepts:**
+    - [Deposit Authorization](depositauth.html)
+    - [Freezing Issued Currencies](freezes.html)
+- **Tutorials:**
+    - [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
+- **References:**
+    - [account_lines method][]
+    - [account_info method][]
+    - [AccountSet transaction][]
+    - [TrustSet transaction][]
+    - [AccountRoot Flags](accountroot.html#accountroot-flags)
+    - [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
 {% include '_snippets/tx-type-links.md' %}			
diff --git a/content/concepts/issued-currencies/freezes.md b/content/concepts/issued-currencies/freezes.md
index 803b9184ab..2b216813ae 100644
--- a/content/concepts/issued-currencies/freezes.md
+++ b/content/concepts/issued-currencies/freezes.md
@@ -420,8 +420,15 @@ Example JavaScript (ECMAScript 6) code to check whether an address has Global Fr
 
 # See Also
 
-* [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
-* [Freeze Code Samples](https://github.com/ripple/ripple-dev-portal/tree/master/content/_code-samples/freeze)
+- [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
+- [Freeze Code Samples](https://github.com/ripple/ripple-dev-portal/tree/master/content/_code-samples/freeze)
+- **References:**
+    - [account_lines method][]
+    - [account_info method][]
+    - [AccountSet transaction][]
+    - [TrustSet transaction][]
+    - [AccountRoot Flags](accountroot.html#accountroot-flags)
+    - [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
diff --git a/content/concepts/issued-currencies/issuing-and-operational-addresses.md b/content/concepts/issued-currencies/issuing-and-operational-addresses.md
index 383b605973..32deb4269a 100644
--- a/content/concepts/issued-currencies/issuing-and-operational-addresses.md
+++ b/content/concepts/issued-currencies/issuing-and-operational-addresses.md
@@ -50,3 +50,17 @@ As with operational addresses, a standby address must have an accounting relatio
 ### Standby Address Compromise
 
 If a standby address is compromised, the consequences are like an operational address being compromised. A malicious actor can steal any balances possessed by the standby address, and the financial institution can change to a new standby address with no action from customers and partners.
+
+## See Also
+
+- **Concepts:**
+    - [Accounts](accounts.html)
+    - [Cryptographic Keys](cryptographic-keys.html)
+- **Tutorials:**
+    - [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
+    - [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
+    - [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
+- **References:**
+    - [account_info method][]
+    - [SetRegularKey transaction][]
+    - [AccountRoot object](accountroot.html)
diff --git a/content/concepts/issued-currencies/paths.md b/content/concepts/issued-currencies/paths.md
index 08a65bbee7..9827bc7fc7 100644
--- a/content/concepts/issued-currencies/paths.md
+++ b/content/concepts/issued-currencies/paths.md
@@ -93,6 +93,19 @@ The `type` field, used for the binary serialization of a path set, is actually c
 | 0x10        | 16              | A change of currency: the `currency` field is present. |
 | 0x20        | 32              | A change of issuer: the `issuer` field is present. |
 
+
+## See Also
+
+- **Concepts:**
+    - [Cross-Currency Payments](cross-currency-payments.html)
+    - [Decentralized Exchange](decentralized-exchange.html)
+    - [Partial Payments](partial-payments.html)
+- **References:**
+    - [Payment transaction][]
+    - [path_find method][] (WebSocket only)
+    - [ripple_path_find method][]
+
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
 {% include '_snippets/tx-type-links.md' %}			
diff --git a/content/concepts/issued-currencies/rippling.md b/content/concepts/issued-currencies/rippling.md
index ea2fca09a0..2270375949 100644
--- a/content/concepts/issued-currencies/rippling.md
+++ b/content/concepts/issued-currencies/rippling.md
@@ -2,7 +2,7 @@
 
 In the XRP Ledger, "rippling" describes a process of atomic net settlement between multiple connected parties who have [trust lines](trust-lines-and-issuing.html) for the same currency. Rippling is an essential part of issued currencies, because it allows users who trust the same issuer to send issued balances to each other with the issuer as a passive intermediary. In a sense, rippling is like a passive, two-way [currency exchange order](offers.html) with no limit and a 1:1 exchange rate for two currencies with the same currency code but different issuers.
 
-Rippling only occurs along the [paths](paths.html) of a payment.
+Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) do not involve rippling.
 
 For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between issuers of the same currency. Thus, the [NoRipple Flag](#the-noripple-flag) disables rippling on incoming trust lines by default, unless the account enables rippling by default by enabling the [DefaultRipple flag](#the-defaultripple-flag).
 
@@ -80,6 +80,21 @@ In the [`rippled` APIs](rippled-api.html), you can use the [account_lines method
 
 In [RippleAPI](rippleapi-reference.html), you can use the [getTrustlines](rippleapi-reference.html#gettrustlines) method to look up the trust lines associated with an address. For each trust line, the `ripplingDisabled` field shows whether the current address has enabled the NoRipple flag on that trust line, and the `counterparty.ripplingDisabled` field shows whether the counterparty has enabled the NoRipple flag.
 
+
+## See Also
+
+- **Concepts:**
+    - [Paths](paths.html)
+- **Tutorials:**
+    - [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
+- **References:**
+    - [account_lines method][]
+    - [account_info method][]
+    - [AccountSet transaction][]
+    - [TrustSet transaction][]
+    - [AccountRoot Flags](accountroot.html#accountroot-flags)
+    - [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
diff --git a/content/concepts/issued-currencies/transfer-fees.md b/content/concepts/issued-currencies/transfer-fees.md
index e030f2bd56..fe814f2de5 100644
--- a/content/concepts/issued-currencies/transfer-fees.md
+++ b/content/concepts/issued-currencies/transfer-fees.md
@@ -49,6 +49,22 @@ A financial institution can submit an [AccountSet transaction][] from its [issui
 
 You can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee.
 
+
+## See Also
+
+- **Concepts:**
+    - [Fees (Disambiguation)](fees.html)
+    - [Transaction Cost](transaction-cost.html)
+    - [Paths](paths.html)
+- **Tutorials:**
+    - [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
+- **References:**
+    - [account_lines method][]
+    - [account_info method][]
+    - [AccountSet transaction][]
+    - [AccountRoot Flags](accountroot.html#accountroot-flags)
+
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
 {% include '_snippets/tx-type-links.md' %}			
diff --git a/content/concepts/issued-currencies/trust-lines-and-issuing.md b/content/concepts/issued-currencies/trust-lines-and-issuing.md
index 747d3f2400..b94a684248 100644
--- a/content/concepts/issued-currencies/trust-lines-and-issuing.md
+++ b/content/concepts/issued-currencies/trust-lines-and-issuing.md
@@ -18,6 +18,19 @@ A trust line with settings in the default state is equivalent to no trust line.
 
 The default state of all trust line flags is off, except for the [NoRipple flag](rippling.html), whose default state depends on the DefaultRipple flag.
 
+## See Also
+
+- **Concepts:**
+    - [Decentralized Exchange](decentralized-exchange.html)
+    - [Rippling](rippling.html)
+- **Tutorials:**
+    - [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
+- **References:**
+    - [account_lines method][]
+    - [gateway_balances method][]
+    - [RippleState (trust line) object](ripplestate.html)
+    - [TrustSet transaction][]
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
diff --git a/content/concepts/payment-types/checks.md b/content/concepts/payment-types/checks.md
index b82fce480a..690efe1a79 100644
--- a/content/concepts/payment-types/checks.md
+++ b/content/concepts/payment-types/checks.md
@@ -81,7 +81,7 @@ Checks require `rippled` v0.90.0 or later. As of 2018-10-11, the Checks amendmen
 To check the status of an amendment on a test net or private XRP Ledger network, use the [feature method][].
 
 
-## Further Reading
+## See Also
 
 For more information about Checks in the XRP Ledger, see:
 
diff --git a/content/concepts/payment-types/complex-payment-types.md b/content/concepts/payment-types/complex-payment-types.md
deleted file mode 100644
index 5318f5d904..0000000000
--- a/content/concepts/payment-types/complex-payment-types.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Complex Payment Types
-
-In addition to simple point-to-point XRP Payments, the XRP Ledger supports a number of complex payment types for a variety of use cases and situations.
diff --git a/content/concepts/payment-types/cross-currency-payments.md b/content/concepts/payment-types/cross-currency-payments.md
index c641044112..93655fa1a8 100644
--- a/content/concepts/payment-types/cross-currency-payments.md
+++ b/content/concepts/payment-types/cross-currency-payments.md
@@ -21,10 +21,15 @@ For more information, see [Autobridging](autobridging.html).
 
 ## See Also
 
-- [Issued Currencies](issued-currencies.html)
-- [Decentralized Exchange](decentralized-exchange.html)
-- [Payment transaction type][Payment transaction]
-- [Paths](paths.html)
+- **Concepts:**
+    - [Issued Currencies](issued-currencies.html)
+    - [Decentralized Exchange](decentralized-exchange.html)
+    - [Paths](paths.html)
+- **References:**
+    - [Payment transaction type][Payment transaction]
+    - [path_find method][]
+    - [ripple_path_find method][]
+    - [Interpreting Metadata of Issued Currency Payments](look-up-transaction-results.html#issued-currency-payments)
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
diff --git a/content/concepts/payment-types/direct-xrp-payments.md b/content/concepts/payment-types/direct-xrp-payments.md
index 047d9437bf..f9d574d1e2 100644
--- a/content/concepts/payment-types/direct-xrp-payments.md
+++ b/content/concepts/payment-types/direct-xrp-payments.md
@@ -73,10 +73,15 @@ From a relatively high level, the XRP Ledger's transaction processing engine app
 
 ## See Also
 
-- [Payment System Basics](payment-system-basics.html)
-- [Payment transaction type][Payment transaction]
-- [Transaction Results](transaction-results.html)
-- [Send XRP (Interactive Tutorial)](send-xrp.html)
+- **Concepts:**
+    - [Payment System Basics](payment-system-basics.html)
+- **Tutorials:**
+    - [Send XRP (Interactive Tutorial)](send-xrp.html)
+    - [Monitor Incoming Payments with WebSocket](Monitor Incoming Payments with WebSocket)
+- **References:**
+    - [Payment transaction][]
+    - [Transaction Results](transaction-results.html)
+    - [account_info method][] - for checking XRP balances
 
 
 <!--{# common link defs #}-->
diff --git a/content/concepts/payment-types/escrow.md b/content/concepts/payment-types/escrow.md
index 37a161246b..eafd03fc8e 100644
--- a/content/concepts/payment-types/escrow.md
+++ b/content/concepts/payment-types/escrow.md
@@ -116,7 +116,7 @@ The most fundamental principle of inter-ledger payments is _conditional transfer
 **Solution:** The Escrow feature makes the XRP Ledger ideal for bridging multi-hop payments using the Interledger Protocol, because it natively supports transfers that deliver XRP based on PREIMAGE-SHA-256 crypto-conditions, and it executes those transfers within seconds of being presented with the matching fulfillment.
 
 
-## Further Reading
+## See Also
 
 For more information about Escrow in the XRP Ledger, see the following:
 
diff --git a/content/concepts/payment-types/payment-channels.md b/content/concepts/payment-types/payment-channels.md
index f10ef8c7a4..f080764c30 100644
--- a/content/concepts/payment-types/payment-channels.md
+++ b/content/concepts/payment-types/payment-channels.md
@@ -27,9 +27,19 @@ The following diagram summarizes the lifecycle of a payment channel:
 
 ## See Also
 
-- [Use Payment Channels](use-payment-channels.html), a tutorial stepping through the process of using a payment channel.
+- **Related Concepts:**
+    - [Escrow](escrow.html), a similar feature for higher-value, lower-speed conditional XRP payments.
+- **Tutorials and Use Cases:**
+    - [Use Payment Channels](use-payment-channels.html), a tutorial stepping through the process of using a payment channel.
+    - [Open a Payment Channel to Enable an Inter-Exchange Network](open-a-payment-channel-to-enable-an-inter-exchange-network.html)
+- **References:**
+    - [channel_authorize method][]
+    - [channel_verify method][]
+    - [PayChannel object](paychannel.html)
+    - [PaymentChannelClaim transaction][]
+    - [PaymentChannelCreate transaction][]
+    - [PaymentChannelFund transaction][]
 
-- [Escrow](escrow.html), a similar feature for higher-value, lower-speed conditional XRP payments.
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			

From 1c48e838b156d1209ab4e9f3d41382aa4371451a Mon Sep 17 00:00:00 2001
From: mDuo13 <mduo13@gmail.com>
Date: Thu, 25 Jul 2019 15:06:21 -0700
Subject: [PATCH 3/8] IA: more links in paths article

---
 content/concepts/issued-currencies/paths.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/content/concepts/issued-currencies/paths.md b/content/concepts/issued-currencies/paths.md
index 9827bc7fc7..04dda0ecaf 100644
--- a/content/concepts/issued-currencies/paths.md
+++ b/content/concepts/issued-currencies/paths.md
@@ -1,10 +1,10 @@
 # Paths
 
-In the XRP Ledger, paths define a way for payments to flow through intermediary steps on their way from sender to receiver. Paths enable cross-currency payments by connecting sender and receiver through order books. Paths also enable complex settlement of offsetting debts.
+In the XRP Ledger, paths define a way for [issued currency](issued-currencies-overview.html) payments to flow through intermediary steps on their way from sender to receiver. Paths enable [cross-currency payments](cross-currency-payments.html) by connecting sender and receiver through orders in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). Paths also enable complex settlement of offsetting debts.
 
 A single Payment transaction in the XRP Ledger can use multiple paths, combining liquidity from different sources to deliver the desired amount. Thus, a transaction includes a _path set_, which is a collection of possible paths to take. The paths in a path set must start and end with the same currency.
 
-Since XRP can be sent directly to any address, an XRP-to-XRP transaction does not use any paths.
+Since XRP can be sent directly to any address, an [XRP-to-XRP transaction](direct-xrp-payments.html) does not use any paths.
 
 ## Path Steps
 

From 1b16b460b6a8c73f9cebfe5c02303e457934fa61 Mon Sep 17 00:00:00 2001
From: mDuo13 <mduo13@gmail.com>
Date: Wed, 31 Jul 2019 17:14:21 -0700
Subject: [PATCH 4/8] IA: add more interlinking / 'See Also' to concepts

---
 .../concepts/consensus-network/consensus.md   |  7 +++++++
 .../decentralized-exchange/autobridging.md    |  8 ++++---
 .../concepts/decentralized-exchange/offers.md | 12 +++++++++++
 .../decentralized-exchange/ticksize.md        |  5 ++++-
 .../concepts/the-rippled-server/clustering.md | 11 +++++++++-
 .../ledger-history/history-sharding.md        | 15 ++++++++++---
 .../ledger-history/ledger-history.md          | 18 ++++++++++++++++
 .../ledger-history/online-deletion.md         | 21 ++++++++++++++-----
 .../the-rippled-server/peer-protocol.md       | 14 +++++++++++++
 .../rippled-server-modes.md                   | 17 ++++++++++++++-
 .../transaction-censorship-detection.md       | 11 ++++++++++
 11 files changed, 125 insertions(+), 14 deletions(-)

diff --git a/content/concepts/consensus-network/consensus.md b/content/concepts/consensus-network/consensus.md
index 31029d76a4..e095075fd0 100644
--- a/content/concepts/consensus-network/consensus.md
+++ b/content/concepts/consensus-network/consensus.md
@@ -176,6 +176,7 @@ Best practices for applications submitting transactions include:
     - [consensus_info method][]
     - [validator_list_sites method][]
     - [validators method][]
+    - [consensus_info method][]
 
 
 
@@ -202,3 +203,9 @@ Best practices for applications submitting transactions include:
 <a href="#from_footnote_9" id="footnote_9"><sup>9</sup></a> – In practice, the XRP Ledger runs more efficiently by starting a new round of consensus concurrently, before validation has completed.
 
 <a href="#from_footnote_10" id="footnote_10"><sup>10</sup></a> – A `rippled` server can respond to API requests even without a complete ledger history. Interruptions in service or network connectivity can lead to missing ledgers, or gaps, in the server’s ledger history. Over time, if configured to, `rippled` fills in gaps in its history. When testing for missing transactions, it is important to verify against a server with continuous complete ledgers from the time the transaction was submitted until its LastLedgerSequence. Use the RPC server_state to determine which complete_ledgers are available to a particular server.
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}
diff --git a/content/concepts/decentralized-exchange/autobridging.md b/content/concepts/decentralized-exchange/autobridging.md
index 8347922edc..c0c400223a 100644
--- a/content/concepts/decentralized-exchange/autobridging.md
+++ b/content/concepts/decentralized-exchange/autobridging.md
@@ -1,13 +1,15 @@
 # Auto-Bridging
 
-Any OfferCreate that would exchange two non-XRP currencies could potentially use XRP as an intermediary currency in a synthetic order book. This is because of auto-bridging, which serves to improve liquidity across all currency pairs by using XRP as a vehicle currency. This works because of XRP's nature as a native cryptocurrency to the XRP Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.
+Any [Offer](offers.html) in the XRP Ledger's [decentralized exchange](decentralized-exchange.html) that would exchange two non-XRP currencies could potentially use [XRP](xrp.html) as an intermediary currency in a synthetic order book. This is because of _auto-bridging_, which serves to improve liquidity across all currency pairs by using XRP when doing so is cheaper than trading those currencies directly. This works because of XRP's nature as a native cryptocurrency to the XRP Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.
 
-Example: _Anita places an offer to sell GBP and buy BRL. She might find that this uncommon currency market has few offers. There is one offer with a good rate, but it has insufficient quantity to satisfy Anita's trade. However, both GBP and BRL have active, competitive markets to XRP. Auto-bridging software finds a way to complete Anita's offer by purchasing XRP with GBP from one trader, then selling the XRP to another trader to buy BRL. Anita automatically gets the best rate possible by combining the small offer in the direct GBP:BRL market with the better composite rates created by pairing GBP:XRP and XRP:BRL offers._
+Example: _Anita places an offer to sell GBP and buy BRL. She might find that this uncommon currency market has few offers. There is one offer with a good rate, but it has insufficient quantity to satisfy Anita's trade. However, both GBP and BRL have active, competitive markets to XRP. The XRP Ledger's auto-bridging system finds a way to complete Anita's offer by purchasing XRP with GBP from one trader, then selling the XRP to another trader to buy BRL. Anita automatically gets the best rate possible by combining the small offer in the direct GBP:BRL market with the better composite rates created by pairing GBP:XRP and XRP:BRL offers._
 
-Auto-bridging happens automatically on any OfferCreate transaction. [Payment transactions](payment.html) _do not_ autobridge by default, but path-finding can find paths that have the same effect.
+Auto-bridging happens automatically on any [OfferCreate transaction][]. [Payment transactions](payment.html) _do not_ autobridge by default, but path-finding can find [paths](paths.html) that have the same effect.
 
 ## See Also
 
 - [Dev Blog: Introducing Autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html)
 
 - [Offer Preference](offers.html#offer-preference)
+
+- [Payment Paths](paths.html)
diff --git a/content/concepts/decentralized-exchange/offers.md b/content/concepts/decentralized-exchange/offers.md
index c9d196c720..32465f0940 100644
--- a/content/concepts/decentralized-exchange/offers.md
+++ b/content/concepts/decentralized-exchange/offers.md
@@ -68,6 +68,18 @@ You can determine the final disposition of an offer with an `Expiration` as soon
 
 If an OfferCreate transaction has an `Expiration` time that has already passed when the transaction first gets included in a ledger, the transaction does not execute the offer. The result code of such a transaction depends on whether the [Checks amendment][]:not_enabled: is enabled. With the Checks amendment enabled, the transaction has the `tecEXPIRED` result code. Otherwise, the transaction has the `tesSUCCESS` transaction code. In either case, the transaction has no effect except to destroy the XRP paid as a [transaction cost](transaction-cost.html).
 
+## See Also
+
+- **Concepts:**
+    - [Issued Currencies Overview](issued-currencies-overview.html)
+    - [Paths](paths.html)
+- **Tutorials:**
+    - [List Your Exchange on XRP Charts](list-your-exchange-on-xrp-charts.html) - for off-ledger exchanges
+- **References:**
+    - [account_offers method][]
+    - [book_offers method][]
+    - [OfferCreate transaction][]
+    - [Offer object](offer.html)
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
diff --git a/content/concepts/decentralized-exchange/ticksize.md b/content/concepts/decentralized-exchange/ticksize.md
index 66ed58168d..dbfee43983 100644
--- a/content/concepts/decentralized-exchange/ticksize.md
+++ b/content/concepts/decentralized-exchange/ticksize.md
@@ -13,8 +13,11 @@ When an issuer enables, disables, or changes the `TickSize`, Offers that were pl
 ## See Also
 
 - [Dev Blog: Introducing the TickSize Amendment](https://xrpl.org/blog/2017/ticksize-voting.html#ticksize-amendment-overview)
+- **References:**
+    - [AccountSet transaction][]
+    - [book_offers method][]
+    - [CreateOffer transaction][]
 
-- [AccountSet transaction][]
 
 
 <!--{# common link defs #}-->
diff --git a/content/concepts/the-rippled-server/clustering.md b/content/concepts/the-rippled-server/clustering.md
index 7a12e784dd..e9d4c8b6aa 100644
--- a/content/concepts/the-rippled-server/clustering.md
+++ b/content/concepts/the-rippled-server/clustering.md
@@ -8,7 +8,16 @@ If you are running multiple `rippled` servers in a single datacenter, you can co
 
 If you are running a validator as a [private peer](peer-protocol.html#private-peers), Ripple recommends using a cluster of `rippled` servers as proxy servers.
 
-For a tutorial on how to set up your servers in a cluster, see [Cluster `rippled` Servers](cluster-rippled-servers.html).
+## See Also
+
+- **Tutorials:**
+    - [Cluster `rippled` Servers](cluster-rippled-servers.html)
+    - [Run rippled as a Validator](run-rippled-as-a-validator.html)
+- **References:**
+    - [peers method][]
+    - [connect method][]
+    - [Peer Crawler](peer-crawler.html)
+
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
diff --git a/content/concepts/the-rippled-server/ledger-history/history-sharding.md b/content/concepts/the-rippled-server/ledger-history/history-sharding.md
index 07d8130801..29a5b87932 100644
--- a/content/concepts/the-rippled-server/ledger-history/history-sharding.md
+++ b/content/concepts/the-rippled-server/ledger-history/history-sharding.md
@@ -26,9 +26,18 @@ The history of all ledgers is shared by servers agreeing to keep particular rang
 
 ## See Also
 
-- [Configure History Sharding](configure-history-sharding.html)
-- [download_shard method][]
-- [crawl_shards method][]
+- **Concepts:**
+    - [Ledgers](ledgers.html)
+    - [Introduction to Consensus](intro-to-consensus.html)
+- **Tutorials:**
+    - [Capacity Planning](capacity-planning.html)
+    - [Configure `rippled`](configure-rippled.html)
+        - [Configure History Sharding](configure-history-sharding.html)
+- **References:**
+    - [crawl_shards method][]
+    - [download_shard method][]
+    - [Peer Crawler](peer-crawler.html)
+
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
diff --git a/content/concepts/the-rippled-server/ledger-history/ledger-history.md b/content/concepts/the-rippled-server/ledger-history/ledger-history.md
index 3181c128d6..e76d5ca6ea 100644
--- a/content/concepts/the-rippled-server/ledger-history/ledger-history.md
+++ b/content/concepts/the-rippled-server/ledger-history/ledger-history.md
@@ -50,6 +50,24 @@ Online deletion **does not** delete from the shard store. However, if you config
 For more information, see [Configure History Sharding](configure-history-sharding.html).
 
 
+## See Also
+
+- **Concepts:**
+    - [Ledgers](ledgers.html)
+    - [Introduction to Consensus](intro-to-consensus.html)
+- **Tutorials:**
+    - [Configure `rippled`](configure-rippled.html)
+        - [Configure Online Deletion](configure-online-deletion.html)
+        - [Configure Advisory Deletion](configure-advisory-deletion.html)
+        - [Configure History Sharding](configure-history-sharding.html)
+        - [Configure Full History](configure-full-history.html)
+- **References:**
+    - [ledger method][]
+    - [server_info method][]
+    - [ledger_request method][]
+    - [can_delete method][]
+    - [ledger_cleaner method][]
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
diff --git a/content/concepts/the-rippled-server/ledger-history/online-deletion.md b/content/concepts/the-rippled-server/ledger-history/online-deletion.md
index 5ec0f0939d..50c37d6ae6 100644
--- a/content/concepts/the-rippled-server/ledger-history/online-deletion.md
+++ b/content/concepts/the-rippled-server/ledger-history/online-deletion.md
@@ -109,11 +109,22 @@ When it comes time for online deletion, the server first walks through the oldes
 
 ## See Also
 
-- [Capacity Planning](capacity-planning.html)
-- [can_delete method][] - API reference documentation
-- [Configure Online Deletion](configure-online-deletion.html)
-- [Configure Advisory Deletion](configure-advisory-deletion.html)
-- [Configure Full History](configure-full-history.html)
+- **Concepts:**
+    - [Ledgers](ledgers.html)
+    - [Introduction to Consensus](intro-to-consensus.html)
+- **Tutorials:**
+    - [Capacity Planning](capacity-planning.html)
+    - [Configure `rippled`](configure-rippled.html)
+        - [Configure Online Deletion](configure-online-deletion.html)
+        - [Configure Advisory Deletion](configure-advisory-deletion.html)
+        - [Configure History Sharding](configure-history-sharding.html)
+        - [Configure Full History](configure-full-history.html)
+- **References:**
+    - [ledger method][]
+    - [server_info method][]
+    - [ledger_request method][]
+    - [can_delete method][]
+    - [ledger_cleaner method][]
 
 
 <!--{# common link defs #}-->
diff --git a/content/concepts/the-rippled-server/peer-protocol.md b/content/concepts/the-rippled-server/peer-protocol.md
index 8f151444de..c915cccb0d 100644
--- a/content/concepts/the-rippled-server/peer-protocol.md
+++ b/content/concepts/the-rippled-server/peer-protocol.md
@@ -69,6 +69,20 @@ Example configuration:
 ```
 
 
+## See Also
+
+- **Concepts:**
+    - [Consensus](consensus.html)
+    - [Parallel Networks](parallel-networks.html)
+- **Tutorials:**
+    - [Configure the Peer Crawler](configure-the-peer-crawler.html)
+- **References:**
+    - [peers method][]
+    - [connect method][]
+    - [fetch_info method][]
+    - [Peer Crawler](peer-crawler.html)
+
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
 {% include '_snippets/tx-type-links.md' %}			
diff --git a/content/concepts/the-rippled-server/rippled-server-modes.md b/content/concepts/the-rippled-server/rippled-server-modes.md
index b9865f92a3..687caba2b7 100644
--- a/content/concepts/the-rippled-server/rippled-server-modes.md
+++ b/content/concepts/the-rippled-server/rippled-server-modes.md
@@ -60,8 +60,23 @@ When you run `rippled` in stand-alone mode, you have to tell it what ledger vers
 
 **Caution:** In stand-alone mode, you must [manually advance the ledger](advance-the-ledger-in-stand-alone-mode.html).
 
+
 ## See Also
 
-- [Commandline Usage Reference](commandline-usage.html) - Detailed information on command-line options for all `rippled` server modes.
+- **References:**
+    - [Commandline Usage Reference](commandline-usage.html) - Detailed information on command-line options for all `rippled` server modes.
+    - [ledger_accept method][] - Manually advance the ledger in stand-alone mode.
+    - [feature method][] - Check [amendments](amendments.html) currently known and enabled.
+- **Tutorials:**
+    - [Configure `rippled`](configure-rippled.html)
+        - [Run `rippled` as a Validator](run-rippled-as-a-validator.html)
+    - [Use rippled in Stand-Alone Mode](use-stand-alone-mode.html):
+        - [Start a New Genesis Ledger in Stand-Alone Mode](start-a-new-genesis-ledger-in-standalone-mode.html)
+        - [Load a Saved Ledger in Stand-Alone Mode](load-a-saved-ledger-in-standalone-mode.html)
+        - [Advance the Ledger in Stand-Alone Mode](advance-the-ledger-in-standalone-mode.html)
 
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
 {% include '_snippets/rippled_versions.md' %}
diff --git a/content/concepts/the-rippled-server/transaction-censorship-detection.md b/content/concepts/the-rippled-server/transaction-censorship-detection.md
index 1431dcf6f2..49ac7dd4d3 100644
--- a/content/concepts/the-rippled-server/transaction-censorship-detection.md
+++ b/content/concepts/the-rippled-server/transaction-censorship-detection.md
@@ -57,5 +57,16 @@ Here are some scenarios that could cause the detector to issue false positive me
     Currently, there are no known bugs that cause this unexpected behavior. However, if you see the impact of what you suspect is a bug, consider reporting it to the [Ripple Bug Bounty](https://ripple.com/bug-bounty/) program.
 
 
+## See Also
+
+- **Concepts:**
+    - [Consensus Principles and Rules](consensus-principles-and-rules.html)
+    - [Transaction Queue](transaction-queue.html)
+- **Tutorials:**
+    - [Reliable Transaction Submission](reliable-transaction-submission.html)
+    - [Understanding Log Messages](understanding-log-messages.html)
+- **References:**
+    - [Transaction Results](transaction-results.html)
+
 
 {% include '_snippets/rippled_versions.md' %}

From 87b9312468b692219ae4cdcdab4ef23a01dfc445 Mon Sep 17 00:00:00 2001
From: mDuo13 <mduo13@gmail.com>
Date: Wed, 31 Jul 2019 17:22:58 -0700
Subject: [PATCH 5/8] Add link defs to autobridging

---
 content/concepts/decentralized-exchange/autobridging.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/content/concepts/decentralized-exchange/autobridging.md b/content/concepts/decentralized-exchange/autobridging.md
index c0c400223a..3061f570ed 100644
--- a/content/concepts/decentralized-exchange/autobridging.md
+++ b/content/concepts/decentralized-exchange/autobridging.md
@@ -13,3 +13,9 @@ Auto-bridging happens automatically on any [OfferCreate transaction][]. [Payment
 - [Offer Preference](offers.html#offer-preference)
 
 - [Payment Paths](paths.html)
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

From 0f3d95fd47e9607237122b910049cdd7b36ec379 Mon Sep 17 00:00:00 2001
From: mDuo13 <mduo13@gmail.com>
Date: Mon, 5 Aug 2019 17:46:23 -0700
Subject: [PATCH 6/8] IA: fix new See Also links

---
 content/concepts/decentralized-exchange/ticksize.md        | 2 +-
 .../issued-currencies/issuing-and-operational-addresses.md | 7 +++++++
 content/concepts/payment-types/direct-xrp-payments.md      | 2 +-
 .../concepts/the-rippled-server/rippled-server-modes.md    | 6 +++---
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/content/concepts/decentralized-exchange/ticksize.md b/content/concepts/decentralized-exchange/ticksize.md
index dbfee43983..b4f2144c05 100644
--- a/content/concepts/decentralized-exchange/ticksize.md
+++ b/content/concepts/decentralized-exchange/ticksize.md
@@ -16,7 +16,7 @@ When an issuer enables, disables, or changes the `TickSize`, Offers that were pl
 - **References:**
     - [AccountSet transaction][]
     - [book_offers method][]
-    - [CreateOffer transaction][]
+    - [OfferCreate transaction][]
 
 
 
diff --git a/content/concepts/issued-currencies/issuing-and-operational-addresses.md b/content/concepts/issued-currencies/issuing-and-operational-addresses.md
index 32deb4269a..292793f0a4 100644
--- a/content/concepts/issued-currencies/issuing-and-operational-addresses.md
+++ b/content/concepts/issued-currencies/issuing-and-operational-addresses.md
@@ -51,6 +51,7 @@ As with operational addresses, a standby address must have an accounting relatio
 
 If a standby address is compromised, the consequences are like an operational address being compromised. A malicious actor can steal any balances possessed by the standby address, and the financial institution can change to a new standby address with no action from customers and partners.
 
+
 ## See Also
 
 - **Concepts:**
@@ -64,3 +65,9 @@ If a standby address is compromised, the consequences are like an operational ad
     - [account_info method][]
     - [SetRegularKey transaction][]
     - [AccountRoot object](accountroot.html)
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
diff --git a/content/concepts/payment-types/direct-xrp-payments.md b/content/concepts/payment-types/direct-xrp-payments.md
index f9d574d1e2..f8e724cb1d 100644
--- a/content/concepts/payment-types/direct-xrp-payments.md
+++ b/content/concepts/payment-types/direct-xrp-payments.md
@@ -77,7 +77,7 @@ From a relatively high level, the XRP Ledger's transaction processing engine app
     - [Payment System Basics](payment-system-basics.html)
 - **Tutorials:**
     - [Send XRP (Interactive Tutorial)](send-xrp.html)
-    - [Monitor Incoming Payments with WebSocket](Monitor Incoming Payments with WebSocket)
+    - [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
 - **References:**
     - [Payment transaction][]
     - [Transaction Results](transaction-results.html)
diff --git a/content/concepts/the-rippled-server/rippled-server-modes.md b/content/concepts/the-rippled-server/rippled-server-modes.md
index 687caba2b7..e221e50b70 100644
--- a/content/concepts/the-rippled-server/rippled-server-modes.md
+++ b/content/concepts/the-rippled-server/rippled-server-modes.md
@@ -71,9 +71,9 @@ When you run `rippled` in stand-alone mode, you have to tell it what ledger vers
     - [Configure `rippled`](configure-rippled.html)
         - [Run `rippled` as a Validator](run-rippled-as-a-validator.html)
     - [Use rippled in Stand-Alone Mode](use-stand-alone-mode.html):
-        - [Start a New Genesis Ledger in Stand-Alone Mode](start-a-new-genesis-ledger-in-standalone-mode.html)
-        - [Load a Saved Ledger in Stand-Alone Mode](load-a-saved-ledger-in-standalone-mode.html)
-        - [Advance the Ledger in Stand-Alone Mode](advance-the-ledger-in-standalone-mode.html)
+        - [Start a New Genesis Ledger in Stand-Alone Mode](start-a-new-genesis-ledger-in-stand-alone-mode.html)
+        - [Load a Saved Ledger in Stand-Alone Mode](load-a-saved-ledger-in-stand-alone-mode.html)
+        - [Advance the Ledger in Stand-Alone Mode](advance-the-ledger-in-stand-alone-mode.html)
 
 
 <!--{# common link defs #}-->

From 40f8bdc4a15e4f2efa339306284ce3b9ef788b11 Mon Sep 17 00:00:00 2001
From: mDuo13 <mduo13@gmail.com>
Date: Tue, 13 Aug 2019 14:24:28 -0700
Subject: [PATCH 7/8] Interlinking: add missed concepts pages, etc.

---
 .../amendments/amendments.md                  | 14 +++++++
 .../consensus-principles-and-rules.md         | 37 ++++++++++++++-----
 .../concepts/consensus-network/consensus.md   |  3 +-
 .../concepts/consensus-network/fee-voting.md  | 16 ++++++++
 .../consensus-network/parallel-networks.md    | 14 +++++++
 .../transaction-malleability.md               | 14 +++++++
 .../issued-currencies-overview.md             | 23 +++++++++++-
 .../accounts/cryptographic-keys.md            | 16 +++++++-
 .../transaction-basics/transaction-basics.md  | 23 ++++++++++++
 .../transaction-basics/transaction-cost.md    | 15 ++++++++
 .../payment-types/partial-payments.md         | 18 +++++++++
 11 files changed, 179 insertions(+), 14 deletions(-)

diff --git a/content/concepts/consensus-network/amendments/amendments.md b/content/concepts/consensus-network/amendments/amendments.md
index 109e65641d..1035e3b7e7 100644
--- a/content/concepts/consensus-network/amendments/amendments.md
+++ b/content/concepts/consensus-network/amendments/amendments.md
@@ -232,6 +232,20 @@ TrustSetAuth
 ```
 
 
+## See Also
+
+- **Concepts:**
+    - [Known Amendments List](known-amendments.html)
+    - [Introduction to Consensus](intro-to-consensus.html)
+- **Tutorials:**
+    - [Run rippled as a Validator](run-rippled-as-a-validator.html)
+    - [Contribute Code to rippled](contribute-code-to-rippled.html)
+- **References:**
+    - [Amendments ledger object](amendments-object.html)
+    - [EnableAmendment pseudo-transaction][]
+    - [feature method][]
+    - [server_info method][]
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
 {% include '_snippets/tx-type-links.md' %}			
diff --git a/content/concepts/consensus-network/consensus-principles-and-rules.md b/content/concepts/consensus-network/consensus-principles-and-rules.md
index 1cd408acef..11e13e7f3d 100644
--- a/content/concepts/consensus-network/consensus-principles-and-rules.md
+++ b/content/concepts/consensus-network/consensus-principles-and-rules.md
@@ -4,16 +4,16 @@ The XRP Ledger is a universal payment system enabling users to transfer funds ac
 
 The XRP Ledger's technology enables near real-time settlement (three to six seconds) and contains a decentralized exchange, where payments automatically use the cheapest currency trade orders available to bridge currencies.
 
-# Background
+## Background
 
-## Mechanics
+### Mechanics
 
 At the core, the XRP Ledger is a shared database that records information such as accounts, balances, and offers to trade assets. Signed instructions called "transactions" cause changes such as creating accounts, making payments, and trading assets.
 
 As a cryptographic system, the owners of XRP Ledger accounts are identified by _cryptographic identities_, which correspond to public/private key pairs. Transactions are authorized by cryptographic signatures matching these identities. Every server processes every transaction according to the same deterministic, known rules. Ultimately, the goal is for every server in the network to have a complete copy of the exact same ledger state, without needing a single central authority to arbitrate transactions.
 
 
-## The Double Spend Problem
+### The Double Spend Problem
 
 The "double spend" problem is a fundamental challenge to operating any sort of payment system. The problem comes from the requirement that when money is spent in one place, it can't also be spent in another place. More generally, the problem occurs when you have any two transactions such that either one is valid but not both together.
 
@@ -26,9 +26,9 @@ Conventionally, payment systems solve the double spend problem by having a centr
 Distributed ledger technologies, like the XRP Ledger, have no central authority. They must solve the double spend problem in some other way.
 
 
-# How Consensus Works
+## How Consensus Works
 
-## Simplifying the Problem
+### Simplifying the Problem
 
 Much of the double spend problem can be solved by well-known rules such as prohibiting an account from spending funds it does not have. In fact, the double spend problem can be reduced to putting transactions in order.
 
@@ -42,7 +42,7 @@ If we could collect transactions into groups and agree on those groupings, we co
 
 The XRP Ledger allows multiple conflicting transactions to be in the agreed group. The group of transactions is executed according to deterministic rules, so whichever transaction comes first according to the sorting rules succeeds and whichever conflicting transaction comes second fails.
 
-## Consensus Rules
+### Consensus Rules
 
 The primary role of consensus is for participants in the process to agree on which transactions are to be processed as a group to resolve the double spend problem. There are four reasons this agreement is easier to achieve than might be expected:
 
@@ -53,7 +53,7 @@ The primary role of consensus is for participants in the process to agree on whi
 
 Every participant’s top priority is correctness. They must first enforce the rules to be sure nothing violates the integrity of the shared ledger. For example, a transaction that is not properly signed must never be processed (even if other participants want to be processed). However, every honest participant’s second priority is agreement. A network with possible double spends has no utility at all. Agreement is facilitated by the fact that every honest participant values it above everything but correctness.
 
-## Consensus Rounds
+### Consensus Rounds
 
 A consensus round is an attempt to agree on a group of transactions so they can be processed. A consensus round starts with each participant who wishes to do so taking an initial position. This is the set of valid transactions they have seen.
 
@@ -63,7 +63,7 @@ To prevent consensus from stalling near 50% and to reduce the overlap required f
 
 When a participant sees a supermajority that agrees on the set of transactions to next be processed, it declares a consensus to have been reached.
 
-## Consensus Can Fail
+### Consensus Can Fail
 
 It is not practical to develop a consensus algorithm that never fails to achieve perfect consensus. To understand why, consider how the consensus process finishes. At some point, each participant must declare that a consensus has been reached and that some set of transactions is known to be the result of the process. This declaration commits that participant irrevocably to some particular set of transactions as the result of the consensus process.
 
@@ -75,7 +75,7 @@ Imagine a group of people in a room trying to agree which door they should use t
 
 The probability of this kind of failure can be made very low, but it cannot be reduced to zero. The engineering tradeoffs are such that driving this probability down below about one in a thousand makes consensus significantly slower, and less able to tolerate network and endpoint failures.
 
-## How the XRP Ledger Handles Consensus Failure
+### How the XRP Ledger Handles Consensus Failure
 
 After a consensus round completes, each participant applies the set of transactions that they believe were agreed to. This results in constructing what they believe the next state of the ledger should be.
 
@@ -95,10 +95,27 @@ Case 3 results in the network losing a few seconds in which it could have made f
 
 On rare occasions, the network as a whole fails to make forward progress for a few seconds. In exchange, average transaction confirmation times are low.
 
-# Philosophy
+## Philosophy
 
 One form of reliability is the ability of a system to provide results even under conditions where some components have failed, some participants are malicious, and so on. While this is important, there is another form of reliability that is much more important in cryptographic payment systems — the ability of a system to produce results that can be relied upon. That is, when a system reports a result to us as reliable, we should be able to rely on that result.
 
 Real-world systems, however, face operational conditions in which both kinds of reliability can be compromised. These include hardware failures, communication failures, and even dishonest participants. Part of the XRP Ledger's design philosophy is to detect conditions where the reliability of results are impaired and report them, rather than providing results that must not be relied on.
 
 The XRP Ledger's consensus algorithm provides a robust alternative to proof of work systems, without consuming computational resources needlessly. Byzantine failures are possible, and do happen, but the consequence is only minor delays. In all cases, the XRP Ledger's consensus algorithm reports results as reliable only when they in fact are.
+
+## See Also
+
+- **Concepts:**
+    - [Introduction to Consensus](intro-to-consensus.html)
+    - [Consensus Research](consensus-research.html)
+    - [Ripple Consensus Video](https://www.youtube.com/watch?v=pj1QVb1vlC0)
+- **Tutorials:**
+    - [Reliable Transaction Submission](reliable-transaction-submission.html)
+    - [Run `rippled` as a Validator](run-rippled-as-a-validator.html)
+- **References:**
+    - [Ledger Format Reference](ledger-data-formats.html)
+    - [Transaction Format Reference](transaction-formats.html)
+    - [consensus_info method][]
+    - [validator_list_sites method][]
+    - [validators method][]
+    - [consensus_info method][]
diff --git a/content/concepts/consensus-network/consensus.md b/content/concepts/consensus-network/consensus.md
index e095075fd0..459a76a7e9 100644
--- a/content/concepts/consensus-network/consensus.md
+++ b/content/concepts/consensus-network/consensus.md
@@ -176,13 +176,12 @@ Best practices for applications submitting transactions include:
     - [consensus_info method][]
     - [validator_list_sites method][]
     - [validators method][]
-    - [consensus_info method][]
 
 
 
 
 
-## End Notes
+## Footnotes
 
 <a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – Transactions with **tec** result codes do not perform the requested action, but do have effects on the ledger. To prevent abuse of the network and to pay for the cost of distributing the transaction, they destroy the XRP transaction cost. To not block other transactions submitted by the same sender around the same time, they increment the sender's account sequence number. They sometimes also perform maintenance such as deleting expired objects or unfunded trade offers.
 
diff --git a/content/concepts/consensus-network/fee-voting.md b/content/concepts/consensus-network/fee-voting.md
index 99d104ede8..7c33a020f7 100644
--- a/content/concepts/consensus-network/fee-voting.md
+++ b/content/concepts/consensus-network/fee-voting.md
@@ -38,3 +38,19 @@ The maximum possible values for the fees are limited by the internal data types
 | `reference_fee` | 2**64 | (More XRP than has ever existed.) |
 | `account_reserve` | 2^32 drops | Approximately 4294 XRP |
 | `owner_reserve` | 2^32 drops | Approximately 4294 XRP |
+
+
+## See Also
+
+- **Concepts:**
+    - [Amendments](amendments.html)
+    - [Transaction Cost](transaction-cost.html)
+    - [Reserves](reserves.html)
+    - [Transaction Queue](transaction-queue.html)
+- **Tutorials:**
+    - [Configure `rippled`](configure-rippled.html)
+- **References:**
+    - [fee method][]
+    - [server_info method][]
+    - [FeeSettings object](feesettings.html)
+    - [SetFee pseudo-transaction][]
diff --git a/content/concepts/consensus-network/parallel-networks.md b/content/concepts/consensus-network/parallel-networks.md
index 6e349b8125..417678cc27 100644
--- a/content/concepts/consensus-network/parallel-networks.md
+++ b/content/concepts/consensus-network/parallel-networks.md
@@ -11,3 +11,17 @@ Over time, there may also be smaller, temporary test networks for specific purpo
 ## Parallel Networks and Consensus
 
 There is no `rippled` setting that defines which network it uses. Instead, it uses the consensus of validators it trusts to know which ledger to accept as the truth. When different consensus groups of `rippled` instances only trust other members of the same group, each group continues as a parallel network. Even if malicious or misbehaving computers connect to both networks, the consensus process overrides the confusion as long as the members of each network are not configured to trust members of another network in excess of their quorum settings.
+
+- **Tools:**
+    - [XRP Test Net Faucet](xrp-test-net-faucet.html)
+- **Concepts:**
+    - [Introduction to Consensus](intro-to-consensus.html)
+    - [Amendments](amendments.html)
+- **Tutorials:**
+    - [Connect Your `rippled` to the XRP Test Net](connect-your-rippled-to-the-xrp-test-net.html)
+    - [Use rippled in Stand-Alone Mode](use-stand-alone-mode.html)
+- **References:**
+    - [server_info method][]
+    - [consensus_info method][]
+    - [validator_list_sites method][]
+    - [validators method][]
diff --git a/content/concepts/consensus-network/transaction-malleability.md b/content/concepts/consensus-network/transaction-malleability.md
index b99acb01e2..aaf6a4d328 100644
--- a/content/concepts/consensus-network/transaction-malleability.md
+++ b/content/concepts/consensus-network/transaction-malleability.md
@@ -141,6 +141,20 @@ The process to exploit a vulnerable system follows a series of steps similar to
     Worse, the vulnerable system might construct a new transaction to replace the transaction, picking new `Sequence`, `LastLedgerSequence`, and `Fee` parameters based on the current state of the network, but keeping the rest of the transaction the same as the original. If this new transaction is also malleable, the system could be exploited in the same way an indefinite number of times.
 
 
+## See Also
+
+- **Concepts:**
+    - [Transaction Basics](transaction-basics.html)
+    - [Finality of Results](finality-of-results.html)
+- **Tutorials:**
+    - [Look Up Transaction Results](look-up-transaction-results.html)
+    - [Reliable Transaction Submission](reliable-transaction-submission.html)
+- **References:**
+    - [Basic Data Types - Hashes](basic-data-types.html#hashes)
+    - [Transaction Common Fields - Global Flags](transaction-common-fields.html#global-flags)
+    - [Transaction Results](transaction-results.html)
+    - [Serialization Format](serialization.html)
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
diff --git a/content/concepts/issued-currencies/issued-currencies-overview.md b/content/concepts/issued-currencies/issued-currencies-overview.md
index d14df685c4..e9d00b2ac5 100644
--- a/content/concepts/issued-currencies/issued-currencies-overview.md
+++ b/content/concepts/issued-currencies/issued-currencies-overview.md
@@ -24,4 +24,25 @@ Addresses can also [freeze](freezes.html) issued currencies, which may be useful
 
 Issued currencies are designed to be able to represent any kind of currency or asset, including those with very small or very large nominal values. For detailed technical information on the types of currency codes and the numeric limits of issued currency representation, see the [currency format reference](currency-formats.html).
 
-{% include '_snippets/tx-type-links.md' %}
+## See Also
+
+- **Concepts:**
+    - [XRP](xrp.html)
+    - [Cross-Currency Payments](cross-currency-payments.html)
+    - [Decentralized Exchange](decentralized-exchange.html)
+- **Tutorials:**
+    - [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
+    - [Look Up Transaction Results](look-up-transaction-results.html)
+    - [Use Specialized Payment Types](use-specialized-payment-types.html)
+- **References:**
+    - [Payment transaction][]
+    - [TrustSet transaction][]
+    - [RippleState object](ripplestate.html)
+    - [account_lines method][]
+    - [account_currencies method][]
+    - [gateway_balances method][]
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}
diff --git a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md
index 9a33bd06c3..a511e2c38d 100644
--- a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md
+++ b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md
@@ -113,7 +113,21 @@ The supported types of key pairs can be used interchangeably throughout the XRP
 
 ### Future Algorithms
 
-In the future, Ripple expects to add new cryptographic signing algorithms to the XRP Ledger to keep up with developments in cryptography. For example, if it seems that quantum computers using [Shor's algorithm](https://en.wikipedia.org/wiki/Shor's_algorithm) (or something similar) will soon be practical enough to break elliptic curve cryptography, Ripple can add a cryptographic signing algorithm that isn't easily broken. As of early 2018, such "quantum-resistant" signing algorithms are relatively impractical and quantum computers are even more impractical, so Ripple has no immediate plans to add any specific algorithms.
+In the future, it is likely that the XRP Ledger will need new cryptographic signing algorithms to keep up with developments in cryptography. For example, if quantum computers using [Shor's algorithm](https://en.wikipedia.org/wiki/Shor's_algorithm) (or something similar) will soon be practical enough to break elliptic curve cryptography, XRP Ledger developers can add a cryptographic signing algorithm that isn't easily broken. As of mid 2019, there's no clear first choice "quantum-resistant" signing algorithm and quantum computers are not yet practical enough to be a threat, so there are no immediate plans to add any specific algorithms. <!-- STYLE_OVERRIDE: will -->
+
+
+## See Also
+
+- **Concepts:**
+    - [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
+- **Tutorials:**
+    - [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
+    - [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
+- **References:**
+    - [SetRegularKey transaction][]
+    - [AccountRoot ledger object](accountroot.html)
+    - [wallet_propose method][]
+    - [account_info method][]
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
diff --git a/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md b/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md
index d8d3df69aa..84ed840e5c 100644
--- a/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md
+++ b/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md
@@ -189,6 +189,29 @@ Example response from the `tx` command:
 }
 ```
 
+## See Also
+
+
+- **Concepts:**
+    - [Payment Types](payment-types.html)
+    - [Consensus Network](consensus-network.html)
+- **Tutorials:**
+    - [Set Up Secure Signing](set-up-secure-signing.html)
+    - [Send XRP](send-xrp.html)
+    - [Look Up Transaction Results](look-up-transaction-results.html)
+    - [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
+    - [Cancel or Skip a Transaction](cancel-or-skip-a-transaction.html)
+    - [Reliable Transaction Submission](reliable-transaction-submission.html)
+- **References:**
+    - [Transaction Common Fields](transaction-common-fields.html)
+    - [Transaction Types](transaction-types.html)
+    - [Transaction Metadata](transaction-metadata.html)
+    - [account_tx method][]
+    - [tx method][]
+    - [submit method][]
+    - [submit_multisigned method][]
+
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
diff --git a/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md b/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md
index 96aaaf4618..c874579cf5 100644
--- a/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md
+++ b/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md
@@ -151,6 +151,21 @@ When the [FeeEscalation amendment][] is enabled, `rippled` prioritizes key reset
 
 The XRP Ledger has a mechanism for changing the minimum transaction cost to account for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](fee-voting.html) for more information.
 
+
+## See Also
+
+- **Concepts:**
+    - [Reserves](reserves.html)
+    - [Fee Voting](fee-voting.html)
+    - [Transaction Queue](transaction-queue.html)
+- **Tutorials:**
+    - [Reliable Transaction Submission](reliable-transaction-submission.html)
+- **References:**
+    - [fee method][]
+    - [server_info method][]
+    - [FeeSettings object](feesettings.html)
+    - [SetFee pseudo-transaction][]
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
 {% include '_snippets/tx-type-links.md' %}			
diff --git a/content/concepts/payment-types/partial-payments.md b/content/concepts/payment-types/partial-payments.md
index 7cb67c049c..a90547f503 100644
--- a/content/concepts/payment-types/partial-payments.md
+++ b/content/concepts/payment-types/partial-payments.md
@@ -105,6 +105,24 @@ Using [the `delivered_amount` field](#the-delivered-amount-field) when processin
 - Add additional sanity checks to your business logic for processing withdrawals. Never process a withdrawal if the total balance you hold in the XRP Ledger does not match your expected assets and obligations.
 - Follow "Know Your Customer" guidelines and strictly verify your customers' identities. You may be able to recognize and block malicious users in advance, or pursue legal action against a malicious actor who exploits your system.
 
+
+## See Also
+
+- **Tools:**
+    - [Transaction Sender](tx-sender.html)
+- **Concepts:**
+    - [Transaction Basics](transaction-basics.html)
+- **Tutorials:**
+    - [Look Up Transaction Results](look-up-transaction-results.html)
+    - [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
+    - [Use Specialized Payment Types](use-specialized-payment-types.html)
+    - [List XRP as an Exchange](list-xrp-as-an-exchange.html)
+- **References:**
+    - [Payment transaction][]
+    - [Transaction Metadata](transaction-metadata.html)
+    - [account_tx method][]
+    - [tx method][]
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
 {% include '_snippets/tx-type-links.md' %}			

From 4af8b8daaab2ceba1bc0d8f69b7f4a194a47c207 Mon Sep 17 00:00:00 2001
From: mDuo13 <mduo13@gmail.com>
Date: Thu, 15 Aug 2019 14:35:55 -0700
Subject: [PATCH 8/8] Interlinking: add missing link def includes

---
 .../consensus-network/consensus-principles-and-rules.md    | 6 ++++++
 content/concepts/consensus-network/fee-voting.md           | 7 +++++++
 content/concepts/consensus-network/parallel-networks.md    | 6 ++++++
 3 files changed, 19 insertions(+)

diff --git a/content/concepts/consensus-network/consensus-principles-and-rules.md b/content/concepts/consensus-network/consensus-principles-and-rules.md
index 11e13e7f3d..14a5b26e8f 100644
--- a/content/concepts/consensus-network/consensus-principles-and-rules.md
+++ b/content/concepts/consensus-network/consensus-principles-and-rules.md
@@ -119,3 +119,9 @@ The XRP Ledger's consensus algorithm provides a robust alternative to proof of w
     - [validator_list_sites method][]
     - [validators method][]
     - [consensus_info method][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
diff --git a/content/concepts/consensus-network/fee-voting.md b/content/concepts/consensus-network/fee-voting.md
index 7c33a020f7..9e7c14c545 100644
--- a/content/concepts/consensus-network/fee-voting.md
+++ b/content/concepts/consensus-network/fee-voting.md
@@ -54,3 +54,10 @@ The maximum possible values for the fees are limited by the internal data types
     - [server_info method][]
     - [FeeSettings object](feesettings.html)
     - [SetFee pseudo-transaction][]
+
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
diff --git a/content/concepts/consensus-network/parallel-networks.md b/content/concepts/consensus-network/parallel-networks.md
index 417678cc27..4190e62eef 100644
--- a/content/concepts/consensus-network/parallel-networks.md
+++ b/content/concepts/consensus-network/parallel-networks.md
@@ -25,3 +25,9 @@ There is no `rippled` setting that defines which network it uses. Instead, it us
     - [consensus_info method][]
     - [validator_list_sites method][]
     - [validators method][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}