fix concept rando links

content/concepts/complex-payment-types/escrow.md

@@ -12,9 +12,9 @@ The XRP set aside in an escrow is locked up. No one can use or destroy the XRP u
 
 **Step 1:** To send an escrow, the sender uses an [EscrowCreate transaction][] to lock up some XRP. This transaction defines a finish time, an expiration time, or both. The transaction may also define a crypto-condition that must be fulfilled to finish the escrow. This transaction must define an intended recipient for the XRP; the recipient _may_ be the same as the sender.
 
-**Step 2:** After this transaction has been processed, the XRP Ledger has an [Escrow object](reference-ledger-format.html#escrow) that holds the escrowed XRP. This object contains the properties of the escrow as defined by the transaction that created it. If this escrow has a finish time, no one can access the XRP before then.
+**Step 2:** After this transaction has been processed, the XRP Ledger has an [Escrow object](escrow-object.html) that holds the escrowed XRP. This object contains the properties of the escrow as defined by the transaction that created it. If this escrow has a finish time, no one can access the XRP before then.
 
-**Step 3:** The recipient, or any other XRP Ledger address, sends an [EscrowFinish transaction][] to deliver the XRP. If the correct conditions are met, this destroys the Escrow object in the ledger and credits the XRP to the intended recipient. If the escrow has a crypto-condition, this transaction must include a fulfillment for that condition. If the escrow has an expiration time that has already passed, the EscrowFinish transaction instead fails with the code [`tecNO_PERMISSION`](reference-transaction-format.html#tec-codes).
+**Step 3:** The recipient, or any other XRP Ledger address, sends an [EscrowFinish transaction][] to deliver the XRP. If the correct conditions are met, this destroys the Escrow object in the ledger and credits the XRP to the intended recipient. If the escrow has a crypto-condition, this transaction must include a fulfillment for that condition. If the escrow has an expiration time that has already passed, the EscrowFinish transaction instead fails with the code [`tecNO_PERMISSION`](tec-codes.html).
 
 ### Expiration Case
 
@@ -24,7 +24,7 @@ All escrows start the same way, so **Steps 1 and 2** are the same as in the succ
 
 **Step 3a:** If the escrow has an expiration time, and it has not been successfully finished before then, the escrow is considered expired. It continues to exist in the XRP Ledger, but can no longer successfully finish. (Expired objects remain in the ledger until a transaction modifies them. Time-based triggers cannot change the ledger contents.)
 
-**Step 4a:** The sender, or any other XRP Ledger address, sends an [EscrowCancel transaction][] to cancel the expired escrow. This destroys the [Escrow object](reference-ledger-format.html#escrow) in the ledger and returns the XRP to the sender.
+**Step 4a:** The sender, or any other XRP Ledger address, sends an [EscrowCancel transaction][] to cancel the expired escrow. This destroys the [Escrow object](escrow-object.html) in the ledger and returns the XRP to the sender.
 
 ## Limitations
 
@@ -37,7 +37,7 @@ Escrow is designed as a feature to enable the XRP Ledger to be used in the [Inte
 - Timed releases and expirations are limited to the resolution of XRP Ledger closes. This means that, in practice, times may be rounded to approximately 5 second intervals, depending on exactly when the ledgers close.
 - The only supported [crypto-condition][] type is PREIMAGE-SHA-256.
 
-Escrow provides strong guarantees that are best suited for high-value, low-quantity payments. [Payment Channels](use-payment-channels.html) are better suited for fast, low-value payments. Of course, unconditional [Payments](reference-transaction-format.html#payment) are also preferable for many use cases.
+Escrow provides strong guarantees that are best suited for high-value, low-quantity payments. [Payment Channels](use-payment-channels.html) are better suited for fast, low-value payments. Of course, unconditional [Payments](payment.html) are also preferable for many use cases.
 
 ## Availability of Escrow
 
@@ -56,7 +56,7 @@ When using [crypto-conditions][], the EscrowFinish transaction must pay a [highe
 
 If the escrow is purely time-locked with no crypto-condition, the EscrowFinish costs only the standard [transaction cost](transaction-cost.html) for a reference transaction.
 
-The additional transaction cost required is proportional to the size of the fulfillment. Currently, an EscrowFinish with a fulfillment requires a minimum transaction cost of **330 [drops of XRP](reference-rippled.html#specifying-currency-amounts) plus 10 drops per 16 bytes in the size of the fulfillment**. If the transaction is [multi-signed](reference-transaction-format.html#multi-signing), the cost of multi-signing is added to the cost of the fulfillment.
+The additional transaction cost required is proportional to the size of the fulfillment. Currently, an EscrowFinish with a fulfillment requires a minimum transaction cost of **330 [drops of XRP](basic-data-types.html#specifying-currency-amounts) plus 10 drops per 16 bytes in the size of the fulfillment**. If the transaction is [multi-signed](multi-signing.html), the cost of multi-signing is added to the cost of the fulfillment.
 
 **Note:** The above formula is based on the assumption that the reference cost of a transaction is 10 drops of XRP.
 
@@ -96,21 +96,20 @@ 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
 
 For more information about Escrow in the XRP Ledger, see the following:
 
-- [Escrow Tutorials](tutorial-escrow.html)
+- [Escrow Tutorials](use-escrows.html)
-    - [Send a Time-Held Escrow](tutorial-escrow.html#send-a-time-held-escrow)
+    - [Send a Time-Held Escrow](send-a-time-held-escrow.html)
-    - [Send a conditionally-held escrow](tutorial-escrow.html#send-a-conditionally-held-escrow)
+    - [Send a conditionally-held escrow](send-a-conditionally-held-escrow.html)
-    - [Look up escrows by sender or receiver](tutorial-escrow.html#look-up-escrows)
+    - [Look up escrows by sender or receiver](look-up-escrows.html)
-- [Transaction Reference](reference-transaction-format.html)
+- [Transaction Reference](transaction-formats.html)
     - [EscrowCreate transaction][]
     - [EscrowFinish transaction][]
     - [EscrowCancel transaction][]
-- [Ledger Reference](reference-ledger-format.html)
+- [Ledger Reference](ledger-data-formats.html)
-    - [Escrow object](reference-ledger-format.html#escrow)
+    - [Escrow object](escrow-object.html)
 
 For more information on Interledger and how conditional transfers enable secure payments across multiple ledgers, see [Interledger Architecture](https://interledger.org/rfcs/0001-interledger-architecture/).
 

content/concepts/introduction/xrp-ledger-overview.md

@@ -71,7 +71,7 @@ As an entity that is obligated to hold large amounts of XRP for the long term, R
 
 Cryptography is one of the hardest parts of any distributed system, and a mistake can lead to money stolen by malicious actors anywhere in the world. The XRP Ledger uses industry-standard schemes for signing and verifying transactions, algorithms that have successfully protected hundreds of billions of US dollars' worth of value for many years. The XRP Ledger also layers multi-signing functionality so you can use multi-factor authorization or split keys across multiple people as a backup, and provides new algorithms with a path to migrate the keys you use if a breakthrough in cryptography makes the old algorithms obsolete.
 
-For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Multi-signing](reference-transaction-format.html#multi-signing).
+For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Multi-Signing](#multi-signing).
 
 
 ## Modern Features for Smart Contracts

content/concepts/introduction/xrp.md

@@ -12,4 +12,4 @@ For more information on XRP's use cases, benefits, and news, see the [XRP Portal
 
 The very first ledger contained 100 billion XRP, and no new XRP can be created. XRP can be destroyed by [transaction costs](transaction-cost.html) or lost by sending it to addresses for which no one holds a key, so XRP is slightly [deflationary](https://en.wikipedia.org/wiki/Deflation) by nature. No need to worry about running out, though: at the current rate of destruction, it would take at least 70,000 years to destroy all XRP, and XRP [prices and fees can be adjusted](fee-voting.html) as the total supply of XRP changes.
 
-In technical contexts, XRP is measured precisely to the nearest 0.000001 XRP, called a "drop" of XRP. The [`rippled` APIs](rippled-api.html) require all XRP amounts to be specified in drops of XRP. For example, 1 XRP is represented as `1000000` drops. For more detailed information, see the [currency format reference](currency-formatting.html).
+In technical contexts, XRP is measured precisely to the nearest 0.000001 XRP, called a "drop" of XRP. The [`rippled` APIs](rippled-api.html) require all XRP amounts to be specified in drops of XRP. For example, 1 XRP is represented as `1000000` drops. For more detailed information, see the [currency format reference](currency-formats.html).

content/concepts/issued-currencies/rippling.md

@@ -66,7 +66,7 @@ The NoRipple flag can only be enabled on a trust line if the address has a posit
 
 In the [`rippled` APIs](rippled-api.html), you can enable the NoRipple flag by sending a [TrustSet transaction][] with the `tfSetNoRipple` flag. You can disable NoRipple (enable rippling) with the `tfClearNoRipple` flag.
 
-In [RippleAPI](rippleapi.html), you can enable the NoRipple flag by sending a [Trustline transaction](rippleapi-reference.html#preparetrustline) transaction with the `ripplingDisabled` field of the trust line set to `true`.
+In [RippleAPI](rippleapi-reference.html), you can enable the NoRipple flag by sending a [Trustline transaction](rippleapi-reference.html#preparetrustline) transaction with the `ripplingDisabled` field of the trust line set to `true`.
 
 
 ### Looking Up NoRipple Status
@@ -75,7 +75,7 @@ In the case of two accounts that mutually trust each other, the NoRipple flag is
 
 In the [`rippled` APIs](rippled-api.html), you can use the [account_lines method][] to look up the trust lines associated with an address. For each trust line, the `no_ripple` field shows whether the current address has enabled the NoRipple flag on that trust line, and the `no_ripple_peer` field shows whether the counterparty has enabled the NoRipple flag.
 
-In [RippleAPI](rippleapi-reference.html), you can use the [getTrustlines](rippleapi.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.
+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.
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}

content/concepts/the-rippled-server/peer-protocol.md

@@ -48,7 +48,7 @@ Each member of the `active` array is a Peer Object with the following fields:
 |:-------------|:-------------------------|:-----------------------------------|
 | `ip`         | String (IPv4 Address)    | The IP address of this connected peer. |
 | `port`       | String (Number)          | The port number on the peer server that serves RTXP. Typically 51235. |
-| `public_key` | String (Base-64 Encoded) | The public key of the ECDSA key pair used by this peer to sign RTXP messages. (This is the same data as the `pubkey_node` reported in the peer server's [`server_info` command](server-info.html).) |
+| `public_key` | String (Base-64 Encoded) | The public key of the ECDSA key pair used by this peer to sign RTXP messages. (This is the same data as the `pubkey_node` reported in the peer server's [`server_info` command](server_info.html).) |
 | `type`       | String                   | The value `in` or `out`, indicating whether the TCP connection to the peer is incoming or outgoing. |
 | `uptime`     | Number                   | The number of seconds the server has been has been connected to this peer. |
 | `version`    | String                   | The `rippled` version number the peer reports to be using. |