Merge pull request #291 from mDuo13/header_cleanup

Standardize header format
2025-11-14 16:55:50 +00:00 · 2018-01-02 15:35:52 -08:00
parent c04f4de7cf 2f494fccf7
commit d0600e7730
15 changed files with 731 additions and 738 deletions
--- a/content/concept-fees.md
+++ b/content/concept-fees.md
@@ -1,26 +1,26 @@
-# Fees (Disambiguation) #
+# Fees (Disambiguation)

 The XRP Ledger is a decentralized ledger, secured by cryptography and operated by a distributed peer-to-peer network of servers. This means that no one party, not even Ripple, can require a fee for access to the network.

 However, the rules of the XRP Ledger include several types of fees, including neutral fees which protect the ledger against abuse. These neutral fees are not paid to anyone. There are also several optional ways that users can collect fees from each other, both inside and outside the XRP Ledger.


-## In the Ledger ##
+## In the Ledger

-### Neutral Fees ###
+### Neutral Fees

 The _**transaction cost**_ (sometimes called the transaction fee) is a miniscule amount of XRP destroyed to send a transaction. This cost scales with the load of the network, which protects the peer-to-peer network from spam. See [Transaction Cost](concept-transaction-cost.html) for more information.

 The _**reserve requirement**_ is a minimum amount of XRP that an account must hold. It increases with the number of objects the account owns in the ledger. This disincentivizes users from increasing the size of the ledger carelessly or maliciously. See [Reserves](concept-reserves.html) for more information.

-### Optional Fees ###
+### Optional Fees

 _**Transfer fees**_ are optional percentage fees that issuers can charge to transfer the currencies they issue to other addresses within the XRP Ledger. See [Transfer Fees](concept-transfer-fees.html) for more information.

 _**Trust line quality**_ is a setting that allows an account to value balances on a trust line at higher or lower than face value. This can lead to situations that are like charging a fee. Trust line quality does not apply to XRP, which is not tied to a trust line.


-## Outside the Ledger ##
+## Outside the Ledger

 Although the fees described above are the only fees built into the XRP Ledger, people can still invent ways to charge fees associated with the ledger. For example, financial institutions commonly charge their customers to send money into and out of the XRP Ledger.

--- a/content/concept-issuing-and-operational-addresses.md
+++ b/content/concept-issuing-and-operational-addresses.md
@@ -1,8 +1,8 @@
-# Issuing and Operational Addresses #
+# Issuing and Operational Addresses

 {% include 'snippets/issuing-and-operational-addresses-intro.md' %}

-## Funds Lifecycle ##
+## Funds Lifecycle

 All non-XRP currency balances (issuances) in the XRP Ledger are tied to accounting relationships between two XRP Ledger addresses. When a financial institution uses Ripple's recommended separation of roles, funds relating to that institution tend to flow in a cycle.

@@ -12,33 +12,33 @@ When the issuing address sends payments, it creates balances in the accounting r

 The issuing address sends issuances to a standby address, or directly to an operational address. The standby addresses send those issuances to operational addresses. Operational addresses send payments to other counterparties, such as liquidity providers, partners, and other customers. Because all issuances are tied to accounting relationships with the issuing address, payments and exchanges of issuances "ripple through" the issuing address. The payment debits the sender's balance in its accounting relationship with the issuing address and credits the recipient's balance in the recipient's accounting relationship with the issuing address. The XRP Ledger also supports more complicated [paths](concept-paths.html) that connect multiple issuers through order books and [liquidity providers who allow their funds to ripple](concept-noripple.html).

-## Issuing Address ##
+## Issuing Address

 The issuing address is like a vault. Partners, customers, and operational addresses create accounting relationships (trust lines) to the issuing address, but this address sends as few transactions as possible. Periodically, a human operator creates and signs a transaction from the issuing address to refill the balances of a standby or operational address. Ideally, the secret key used to sign these transactions should never be accessible from any internet-connected computer.

 Unlike a vault, the issuing address can receive payments directly from customers and partners. Since all transactions in the XRP Ledger are public, automated systems can monitor for payments to the issuing address without needing a secret key.

-### Issuing Address Compromise ###
+### Issuing Address Compromise

 If a malicious actor learns the secret key behind a institution's issuing address, that actor can create new issuances without limit and trade them in the decentralized exchange. This would make it difficult for the financial institution to distinguish legitimately-obtained issuances and redeem them fairly. If a financial institution loses control of its issuing address, the institution must create a new issuing address, and all users who have accounting relationships with the old issuing address must create new accounting relationships with the new address.

-### Multiple Issuing Addresses ###
+### Multiple Issuing Addresses

 A financial institution can issue more than one currency in the XRP Ledger from a single issuing address. However, there are some settings that apply equally to all currencies issued from an address, including the percentage for [transfer fees](concept-transfer-fees.html) and the [global freeze](concept-freeze.html) status. If the financial institution wants the flexibility to manage settings differently for each currency, the institution must use a different issuing address for each currency.


-## Operational Addresses ##
+## Operational Addresses

 An operational address is like a cash register. It makes payments on behalf of the institution by transferring issuances to customers and partners. To sign transactions automatically, the secret key for an operational address must be stored on a server that is connected to the internet. (The secret key can be stored encrypted, but the server must decrypt it to sign transactions.) Customers and partners do not, and should not, create accounting relationships with an operational address.

 Each operational address has a limited balance of issuances. When the balance of an operational address gets low, the financial institution refills it by sending a payment from the issuing address or a standby address.

-### Operational Address Compromise ###
+### Operational Address Compromise

 If a malicious actor learns the secret key behind an operational address, the financial institution can only lose as much currency as that operational address holds. The institution can switch to a new operational address with no action from customers and partners.


-## Standby Addresses ##
+## Standby Addresses

 Another optional step that an institution can take to balance risk and convenience is to use "standby addresses" as an intermediate step between the issuing address and operational addresses. The institution can fund additional XRP Ledger addresses as standby addresses, whose keys are not stored online, but are entrusted to different trusted users.

@@ -46,6 +46,6 @@ When an operational address is running low on funds, a trusted user can use a st

 As with operational addresses, a standby address must have an accounting relationship with the issuing address, and not with customers or partners. All precautions that apply to operational addresses also apply to standby addresses.

-### Standby Address Compromise ###
+### 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.
--- a/content/concept-noripple.md
+++ b/content/concept-noripple.md
@@ -2,7 +2,7 @@

 In the XRP Ledger, the "NoRipple" flag is a setting on a trust line. When an address enables the NoRipple flag on two trust lines, payments from third parties cannot "ripple" through that address on those trust lines. This protects liquidity providers from having balances shift unexpectedly between different issuers of the same currency.

-## Background ##
+## Background

 "Rippling" occurs when more than one trust line is adjusted to make a payment. For example, if Alice owes Charlie money, and Alice also owes Bob money, then you could represent that in the XRP Ledger with trust lines like so:

@@ -14,7 +14,7 @@ If Bob wants to pay $3 to Charlie, then he could say, "Alice, take $3 of the mon

 We call this process, where two addresses pay each other by adjusting the balances of trust lines in between them, "rippling". This is a useful and important feature of the XRP Ledger. Rippling occurs when addresses are linked by trust lines that use the same [currency code](reference-rippled.html#currency-codes). The issuer does not need to be the same: in fact, larger chains always involve changing issuers.

-## Justification ##
+## Justification

 Sometimes you do not want your balances to ripple. For example, imagine Emily has money issued by two different financial institutions, like so

@@ -32,15 +32,15 @@ For example:

 Now the above scenario, where Charlie pays Daniel while rippling through Emily's address, is no longer possible.

-## Specifics ##
+## Specifics

 The NoRipple flag makes certain paths invalid, so that they cannot be used to make payments. A path is considered invalid if and only if it enters **and** exits an address node through trust lines where NoRipple has been enabled for that address.

 ![Diagram demonstrating that NoRipple has to be set on both trust lines by the same address to do anything](img/noripple-06.png)

-## Technical Details ##
+## Technical Details

-### Enabling / Disabling NoRipple ###
+### Enabling / Disabling NoRipple

 The NoRipple flag can only be enabled on a trust line if the address has a positive or zero balance on that trust line. This is so that the feature cannot be abused to default on the obligation the trust line balance represents. (Of course, you can still default by abandoning the address.)

@@ -49,7 +49,7 @@ In the [`rippled` APIs](reference-rippled.html), you can enable the NoRipple fla
 In [RippleAPI](reference-rippleapi.html), you can enable the NoRipple flag by sending a [Trustline transaction](reference-rippleapi.html#preparetrustline) transaction with the `ripplingDisabled` field of the trust line set to `true`.


-### Looking Up NoRipple Status ###
+### Looking Up NoRipple Status

 In the case of two accounts that mutually trust each other, the NoRipple flag is tracked separately for each account.

--- a/content/concept-paths.md
+++ b/content/concept-paths.md
@@ -6,7 +6,7 @@ A single Payment transaction in the XRP Ledger can use multiple paths, combining

 Since XRP can be sent directly to any address, an XRP-to-XRP transaction does not use any paths.

-## Path Steps ##
+## Path Steps

 A path is made of steps that connect the sender to the receiver of the payment. Every step is either:

@@ -23,9 +23,9 @@ In both types of steps, each intermediate address gains and loses approximately



-# Technical Details #
+# Technical Details

-## Pathfinding ##
+## Pathfinding

 The `rippled` API has two methods that can be used for pathfinding. The [`ripple_path_find` command](reference-rippled.html#ripple-path-find) does a one-time lookup of possible path sets. The [`path_find` command](reference-rippled.html#path-find) (WebSocket only) expands on the search with follow-up responses whenever a ledger closes or the server finds a better path.

@@ -36,7 +36,7 @@ You can have `rippled` automatically fill in paths when you sign it, by includin
 Finding paths is a very challenging problem that changes slightly every few seconds as new ledgers are validated, so `rippled` is not designed to find the absolute best path. Still, you can find several possible paths and estimate the cost of delivering a particular amount.


-## Implied Steps ##
+## Implied Steps

 By convention, several steps of a path are implied by the [fields of the Payment transaction](reference-transaction-format.html#payment): specifically, the `Account` (sender), `Destination` (receiver), `Amount` (currency and amount to be delivered) and `SendMax` (currency and amount to be sent, if specified). The implied steps are as follows:

@@ -47,7 +47,7 @@ By convention, several steps of a path are implied by the [fields of the Payment
 * Finally, last step of a path is always implied to be the receiver of a transaction, as defined by the transaction's `Destination` field.


-## Default Paths ##
+## Default Paths

 In addition to explicitly specified paths, a transaction can execute along the _default path_. The default path is the simplest possible way to connect the [implied steps](#implied-steps) of the transaction.

@@ -64,7 +64,7 @@ The following diagram enumerates all possible default paths:
 You can use the [`tfNoDirectRipple` flag](reference-transaction-format.html#payment-flags) to disable the default path. In this case, the transaction can only execute using the paths explicitly included in the transaction. Traders can use this option to take arbitrage opportunities.


-## Path Specifications ##
+## Path Specifications

 A path set is an array. Each member of the path set is another array that represents an individual _path_. Each member of a path is an object that specifies the step. A step has the following fields:

--- a/content/concept-reserves.md
+++ b/content/concept-reserves.md
@@ -1,4 +1,4 @@
-# Reserves #
+# Reserves

 The XRP Ledger applies _reserve requirements_, in XRP, to protect the shared global ledger from growing excessively large as the result of spam or malicious usage. The goal is to constrain the growth of the ledger to match improvements in technology so that a current commodity-level machine can always fit the current ledger in RAM and the full ledger history on disk.

@@ -7,7 +7,7 @@ To submit transactions, an address must hold a minimum amount of XRP in the shar
 The current minimum reserve requirement is **20 XRP**. (This is the cost of an address that owns no other objects in the ledger.)


-## Base Reserve and Owner Reserve ##
+## Base Reserve and Owner Reserve

 The reserve requirement is divided into two parts:

@@ -15,7 +15,7 @@ The reserve requirement is divided into two parts:
 * The **Owner Reserve** is an increase to the reserve requirement for each object that the address owns in the ledger. Currently, this is 5 XRP (`5000000` drops) per item.


-### Owner Reserves ###
+### Owner Reserves

 Many objects in the ledger are owned by a particular address, and count toward the reserve requirement of that address. When objects are removed from the ledger, they no longer count against their owner's reserve requirement.

@@ -26,13 +26,13 @@ Many objects in the ledger are owned by a particular address, and count toward t
 - [Payment Channels](tutorial-paychan.html) are owned by the address that created them.
 - [Owner directories](reference-ledger-format.html#directorynode) list all the ledger objects that contribute to an address's owner reserve. However, the owner directory itself does not count towards the reserve.

-#### Owner Reserve Edge Cases ####
+#### Owner Reserve Edge Cases

 The XRP Ledger considers an [OfferCreate transaction][] to be an explicit statement of willingness to hold an asset. Consuming the offer automatically creates a trust line (with limit 0, and a balance above that limit) for the `taker_pays` currency if such a trust line does not exist. However, if the offer's owner does not hold enough XRP to also meet the owner reserve requirement of the new trust line, the offer is considered unfunded. See also: [Lifecycle of an Offer](reference-transaction-format.html#lifecycle-of-an-offer).



-## Going Below the Reserve Requirement ##
+## Going Below the Reserve Requirement

 During transaction processing, the [transaction cost](concept-transaction-cost.html) destroys some of the sending address's XRP balance. This can cause an address's XRP to go below the reserve requirement.

@@ -40,7 +40,7 @@ When an address holds less XRP than its current reserve requirement, it cannot s

 **Tip:** When an address is below the reserve requirement, it can send new [OfferCreate transactions][] to acquire more XRP, or other currencies on its existing trust lines. These transactions cannot create new [trust lines](reference-ledger-format.html#ripplestate), or [Offer nodes in the ledger](reference-ledger-format.html#offer), so they can only execute trades that consume Offers that are already in the order books.

-## Changing the Reserve Requirements ##
+## Changing the Reserve Requirements

 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](concept-fee-voting.html) for more information.

--- a/content/concept-stand-alone-mode.md
+++ b/content/concept-stand-alone-mode.md
@@ -1,5 +1,4 @@
-Stand-Alone Mode
-===============================================================================
+# Stand-Alone Mode

 You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the XRP Ledger peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior without being tied to the live network. For example, you can [test the effects of Amendments](concept-amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network.

@@ -11,8 +10,8 @@ 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](#advancing-ledgers-in-stand-alone-mode).


-New Genesis Ledger
-------------------------------------------------------------------------------
+## New Genesis Ledger
+
 In stand-alone mode, you can have `rippled` create a new genesis ledger. This provides a known state, with none of the ledger history from the production XRP Ledger. (This is very useful for unit tests, among other things.)

 * To start `rippled` in stand-alone mode with a new genesis ledger, use the [`-a`](https://wiki.ripple.com/Rippled#--standalone.2C_-a) and [`--start`](https://wiki.ripple.com/Rippled#--start) options:
@@ -32,11 +31,11 @@ In a genesis ledger, the [genesis address](concept-accounts.html#special-address
 [New in: rippled 0.50.0][] If you start a new genesis ledger with `--start`, all The genesis ledger contains an [EnableAmendment pseudo-transaction](reference-transaction-format.html#enableamendment) to turn on all [Amendments](concept-amendments.html) natively supported by the `rippled` server, except for amendments that you explicitly disable in the configuration file. The effects of those amendments are available starting from the very next ledger version.


-Load Saved Ledger
-------------------------------------------------------------------------------
+## Load Saved Ledger
+
 You can start with a ledger version that was saved to disk if your `rippled` server was previously synced with the XRP Ledger peer-to-peer network (either the production network or the [Test Net](tutorial-rippled-setup.html#parallel-networks)).

-### 1. Start `rippled` normally. ###
+### 1. Start `rippled` normally.

 To load an existing ledger, you must first retrieve that ledger from the network. Start `rippled` in online mode as normal:

@@ -44,7 +43,7 @@ To load an existing ledger, you must first retrieve that ledger from the network
 rippled --conf=/path/to/rippled.cfg
 ```

-### 2. Wait until `rippled` is synced. ###
+### 2. Wait until `rippled` is synced.

 Use the [`server_info` command](reference-rippled.html#server-info) to check the state of your server relative to the network. Your server is synced when the `server_state` value shows any of the following values:

@@ -54,7 +53,7 @@ Use the [`server_info` command](reference-rippled.html#server-info) to check the

 For more information, see [Possible Server States](reference-rippled.html#possible-server-states).

-### 3. (Optional) Retrieve specific ledger versions. ###
+### 3. (Optional) Retrieve specific ledger versions.

 If you only want the most recent ledger, you can skip this step.

@@ -62,7 +61,7 @@ If you want to load a specific historical ledger version, use the [`ledger_reque

 If you want to replay a specific historical ledger version, you must fetch both the ledger version to replay and the ledger version before it. (The previous ledger version sets up the initial state upon which you apply the changes described by the ledger version you replay.)

-### 4. Shut down `rippled`. ###
+### 4. Shut down `rippled`.

 Use the [`stop` command](reference-rippled.html#stop):

@@ -70,7 +69,7 @@ Use the [`stop` command](reference-rippled.html#stop):
 rippled stop --conf=/path/to/rippled.cfg
 ```

-### 5. Start `rippled` in stand-alone mode. ###
+### 5. Start `rippled` in stand-alone mode.

 To load the most recent ledger version, you can use the [`-a`](https://wiki.ripple.com/Rippled#--standalone.2C_-a) and [`--load`](https://wiki.ripple.com/Rippled#--load) options when starting the server:

@@ -84,7 +83,7 @@ To instead load a specific historical ledger, use the [`--load`](https://wiki.ri
 rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
 ```

-### 6. Manually advance the ledger. ###
+### 6. Manually advance the ledger.

 When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you must [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode):

@@ -93,8 +92,7 @@ rippled ledger_accept --conf=/path/to/rippled.cfg
 ```


-Advancing Ledgers in Stand-Alone Mode
-------------------------------------------------------------------------------
+## Advancing Ledgers in Stand-Alone Mode

 In stand-alone mode, `rippled` does not communicate to other members of the peer-to-peer network or participate in a consensus process. Instead, you must manually advance the ledger index using the [`ledger_accept` command](reference-rippled.html#ledger-accept):

--- a/content/concept-transaction-cost.md
+++ b/content/concept-transaction-cost.md
@@ -1,17 +1,17 @@
-# Transaction Cost #
+# Transaction Cost

 To protect the XRP Ledger from being disrupted by spam and denial-of-service attacks, each transaction must destroy a small amount of [XRP](https://ripple.com/xrp-portal/). This _transaction cost_ is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network.

 Every transaction must [specify how much XRP to destroy](#specifying-the-transaction-cost) to pay the transaction cost.


-## Current Transaction Cost ##
+## Current Transaction Cost

 The current minimum transaction cost required by the network for a standard transaction is **0.00001 XRP** (10 drops). It sometimes increases due to higher than usual load.

 You can also [query `rippled` for the current transaction cost](#querying-the-transaction-cost).

-### Special Transaction Costs ###
+### Special Transaction Costs

 Some transactions have different transaction costs:

@@ -23,12 +23,12 @@ Some transactions have different transaction costs:
 | [EscrowFinish Transaction with Fulfillment](reference-transaction-format.html#escrowfinish) | 10 drops × (33 + (Fulfillment size in bytes ÷ 16)) |


-## Beneficiaries of the Transaction Cost ##
+## Beneficiaries of the Transaction Cost

 The transaction cost is not paid to any party: the XRP is irrevocably destroyed. Since no new XRP can ever be created, this makes XRP more scarce and benefits all holders of XRP by making XRP more valuable.


-## Load Cost and Open Ledger Cost ##
+## Load Cost and Open Ledger Cost

 When the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, there are two thresholds for the transaction cost:

@@ -42,11 +42,11 @@ This divides transactions into roughly three categories:
 * Transactions in between, which get [queued for a later ledger version](#queued-transactions).


-## Local Load Cost ##
+## Local Load Cost

 Each `rippled` server maintains a cost threshold based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an [admin connection](reference-rippled.html#connecting-to-rippled), the server applies and relays the transaction as long as the transaction meets the un-scaled minimum transaction cost.) A transaction is very unlikely to survive [the consensus process](https://ripple.com/build/ripple-ledger-consensus-process/) unless its `Fee` value meets the requirements of a majority of servers.

-## Open Ledger Cost ##
+## Open Ledger Cost

 The `rippled` server has a second mechanism for enforcing the transaction cost, called the _open ledger cost_. A transaction can only be included in the open ledger if it meets the open ledger cost requirement in XRP. Transactions that do not meet the open ledger cost may be [queued for a following ledger](#queued-transactions) instead.

@@ -56,15 +56,15 @@ The open ledger cost requirement is [proportional to the normal cost of the tran

 See also: [Fee Escalation explanation in `rippled` repository](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md).

-### Queued Transactions ###
+### Queued Transactions

-When `rippled` receives a transaction that meet the server's local load cost but not the [open ledger cost](#open-ledger-cost), the server estimates whether the transaction is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network. Otherwise, the server discards the transaction. The server tries to minimize the amount of network load caused by transactions that would not pay a transaction cost, since [the transaction cost only applies when a transaction is included in a validated ledger](#transaction-costs-and-failed-transactions).
+When `rippled` receives a transaction that meets the server's local load cost but not the [open ledger cost](#open-ledger-cost), the server estimates whether the transaction is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network. Otherwise, the server discards the transaction. The server tries to minimize the amount of network load caused by transactions that would not pay a transaction cost, since [the transaction cost only applies when a transaction is included in a validated ledger](#transaction-costs-and-failed-transactions).

 When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first, proportional to the [reference cost](#reference-transaction-cost) of those transactions. Transactions that pay the same transaction cost are queued in the order the server receives them.

 **Note:** When `rippled` queues a transaction, the provisional [transaction response code](reference-transaction-format.html#transaction-results) is `terQUEUED`. This means that the transaction is likely to succeed in a future ledger version. As with all provisional response codes, the outcome of the transaction is not final until the transaction is either included in a validated ledger, or [rendered permanently invalid](reference-transaction-format.html#finality-of-results).

-#### Queuing Restrictions ####
+#### Queuing Restrictions

 The `rippled` server uses a variety of heuristics to estimate which transactions are "likely to be included in a ledger." The current implementation uses the following rules to decide which transactions to queue:

@@ -74,7 +74,7 @@ The `rippled` server uses a variety of heuristics to estimate which transactions
 * If a transaction affects how the sending address authorizes transactions, no other transactions from the same address can be queued behind it. [New in: rippled 0.32.0][]
 * If the transaction includes a `LastLedgerSequence` field, the value of that field must be at least **the current ledger index + 2**.

-#### Fee Averaging ####
+#### Fee Averaging

 [New in: rippled 0.33.0][]

@@ -89,11 +89,11 @@ This feature helps you work around a particular situation. If you submitted one
 If none of the above occur, transactions can stay in the queue for a theoretically unlimited amount of time, while other senders can "cut in line" by submitting transactions with higher transaction costs. Since signed transactions are immutable, you cannot increase the transaction cost of the queued transactions to increase their priority. If you do not want to invalidate the previously submitted transactions, fee averaging provides a workaround. If you increase the transaction cost of your new transaction to compensate, you can ensure the queued transactions are included in an open ledger right away.


-## Reference Transaction Cost ##
+## Reference Transaction Cost

 The "Reference Transaction" is the cheapest (non-free) transaction, in terms of the necessary [transaction cost](concept-transaction-cost.html) before load scaling. Most transactions have the same cost as the reference transaction. Some transactions, such as [multi-signed transactions](reference-transaction-format.html#multi-signing), require a multiple of this cost instead. When the open ledger cost escalates, the requirement is proportional to the basic cost of the transaction.

-### Fee Levels ###
+### Fee Levels

 _Fee levels_ represent the proportional difference between the minimum cost and the actual cost of a transaction. The [Open Ledger Cost](#open-ledger-cost) is measured in fee levels instead of absolute cost. See the following table for a comparison:

@@ -105,20 +105,20 @@ _Fee levels_ represent the proportional difference between the minimum cost and
 | [EscrowFinish transaction](reference-transaction-format.html#escrowfinish) with 32-byte preimage. | 350 | 256 | 700 | 512 |


-## Querying the Transaction Cost ##
+## Querying the Transaction Cost

 The `rippled` APIs have two ways to query the local load-based transaction cost: the `server_info` command (intended for humans) and the `server_state` command (intended for machines).

 If the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, you can use the [`fee` command](reference-rippled.html#fee) to check the open ledger cost.

-### server_info ###
+### server_info

 The [`server_info` command](reference-rippled.html#server-info) reports the unscaled minimum XRP cost, as of the previous ledger, as `validated_ledger.base_fee_xrp`, in the form of decimal XRP. The actual cost necessary to relay a transaction is scaled by multiplying that `base_fee_xrp` value by the `load_factor` parameter in the same response, which represents the server's current load level. In other words:

 **Current Transaction Cost in XRP = `base_fee_xrp` × `load_factor`**


-### server_state ###
+### server_state

 The [`server_state` command](reference-rippled.html#server-state) returns a direct representation of `rippled`'s internal load calculations. In this case, the effective load rate is the ratio of the current `load_factor` to the `load_base`. The `validated_ledger.base_fee` parameter reports the minimum transaction cost in [drops of XRP](reference-rippled.html#specifying-currency-amounts). This design enables `rippled` to calculate the transaction cost using only integer math, while still allowing a reasonable amount of fine-tuning for server load. The actual calculation of the transaction cost is as follows:

@@ -126,7 +126,7 @@ The [`server_state` command](reference-rippled.html#server-state) returns a dire



-## Specifying the Transaction Cost ##
+## Specifying the Transaction Cost

 Every signed transaction must include the transaction cost in the [`Fee` field](reference-transaction-format.html#common-fields). Like all fields of a signed transaction, this field cannot be changed without invalidating the signature.

@@ -135,7 +135,7 @@ As a rule, the XRP Ledger executes transactions _exactly_ as they are signed. (T
 Before signing a transaction, we recommend [looking up the current load-based transaction cost](#querying-the-transaction-cost). If the transaction cost is high due to load scaling, you may want to wait for it to decrease. If you do not plan on submitting the transaction immediately, we recommend specifying a slightly higher transaction cost to account for future load-based fluctuations in the transaction cost.


-### Automatically Specifying the Transaction Cost ###
+### Automatically Specifying the Transaction Cost

 When you sign a transaction online, you can omit the `Fee` field. In this case, `rippled` or [RippleAPI](reference-rippleapi.html) checks the state of the peer-to-peer network for the current requirement and adds a `Fee` value before signing the transaction. However, there are several drawbacks and limitations to automatically filling in the transaction cost in this manner:

@@ -148,7 +148,7 @@ When you sign a transaction online, you can omit the `Fee` field. In this case,



-## Transaction Costs and Failed Transactions ##
+## Transaction Costs and Failed Transactions

 Since the purpose of the transaction cost is to protect the XRP Ledger peer-to-peer network from excessive load, it should apply to any transaction that gets distributed to the network, regardless of whether or not that transaction succeeds. However, to affect the shared global ledger, a transaction must be included in a validated ledger. Thus, `rippled` servers try to include failed transactions in ledgers, with [`tec` status codes](reference-transaction-format.html#result-categories) ("tec" stands for "Transaction Engine - Claimed fee only").

@@ -156,14 +156,14 @@ The transaction cost is only debited from the sender's XRP balance when the tran

 If a transaction's failure is [final](reference-transaction-format.html#finality-of-results), the `rippled` server does not relay it to the network. The transaction does not get included in a validated ledger, so it cannot have any effect on anyone's XRP balance.

-### Insufficient XRP ###
+### Insufficient XRP

 When a `rippled` server initially evaluates a transaction, it rejects the transaction with the error code `terINSUF_FEE_B` if the sending account does not have a high enough XRP balance to pay the XRP transaction cost. Since this is a `ter` (Retry) code, the `rippled` server retries the transaction without relaying it to the network, until the transaction's outcome is [final](reference-transaction-format.html#finality-of-results).

 When a transaction has already been distributed to the network, but the account does not have enough XRP to pay the transaction cost, the result code `tecINSUFF_FEE` occurs instead. In this case, the account pays all the XRP it can, ending with 0 XRP. This can occur because `rippled` decides whether to relay the transaction to the network based on its in-progress ledger, but transactions may be dropped or reordered when building the consensus ledger.


-## Key Reset Transaction ##
+## Key Reset Transaction

 As a special case, an account can send a [SetRegularKey](reference-transaction-format.html#setregularkey) transaction with a transaction cost of `0`, as long as the account's [lsfPasswordSpent flag](reference-ledger-format.html#accountroot-flags) is disabled. This transaction must be signed by the account's _master key pair_. Sending this transaction enables the lsfPasswordSpent flag.

@@ -174,7 +174,7 @@ The [lsfPasswordSpent flag](reference-ledger-format.html#accountroot-flags) star
 When the [FeeEscalation amendment](concept-amendments.html#feeescalation) is enabled, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero.


-## Changing the Transaction Cost ##
+## Changing the Transaction Cost

 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](concept-fee-voting.html) for more information.

--- a/content/concept-transfer-fees.md
+++ b/content/concept-transfer-fees.md
@@ -1,4 +1,4 @@
-# Transfer Fees #
+# Transfer Fees

 The `TransferRate` setting in the XRP Ledger allows [financial institutions that issue currency in the XRP Ledger](tutorial-gateway-guide.html) to charge users a _transfer fee_ for sending the currencies issued by that financial institution. The sender of the transfer is debited an extra percentage based on the transfer fee, while the recipient of the transfer is credited the intended amount. The difference is the transfer fee, which becomes the property of the issuing address, and is no longer tracked in the XRP Ledger. The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address][] to another user.

@@ -13,7 +13,7 @@ The following diagram shows an XRP Ledger payment of 2 EUR.ACME from Alice to Ch

 ![Alice sends 2,02€, Charlie receives 2,00€, and ACME owes 0,02€ less in the XRP Ledger](img/e2g-with_transferrate.png)

-## Transfer Fees in Payment Paths ##
+## Transfer Fees in Payment Paths

 <!--{# TODO: Update this for OnwerPaysFee amendment when that gets added #}-->

@@ -33,7 +33,7 @@ The transfer fee is represented by a setting on the [issuing address][]. The tra

 **Note:** The [fix1201 amendment](concept-amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% (a `TransferRate` of `2000000000`). Any transfer fees already set continue to operate at their stated rate.

-## RippleAPI ##
+## RippleAPI

 In RippleAPI, the transfer fee is specified in the `transferRate` field, as a decimal which represents the amount you must send for the recipient to get 1 unit of the same currency. A `transferRate` of `1.005` is equivalent to a transfer fee of 0.5%. By default, the `transferRate` is set to no fee. The value of `transferRate` cannot be less than `1.0` or more than `2.0`. The value `null` is a special case for no fee, equivalent to `1000000000`.

@@ -41,7 +41,7 @@ A financial institution can send a [Settings transaction](reference-rippleapi.ht

 You can check an account's `transferRate` with the [getSettings method](reference-rippleapi.html#getsettings).

-## rippled ##
+## rippled

 In `rippled`'s JSON-RPC and WebSocket APIs, the transfer fee is specified in the `TransferRate` field, as an integer which represents the amount you must send for the recipient to get 1 billion units of the same currency. A `TransferRate` of `1005000000` is equivalent to a transfer fee of 0.5%. By default, the `TransferRate` is set to no fee. The value of `TransferRate` cannot be set to less than `1000000000` or more than `2000000000` (a "100%" fee). The value `0` is special case for no fee, equivalent to `1000000000`.

--- a/content/reference-data-api.md
+++ b/content/reference-data-api.md
--- a/content/reference-rippled.md
+++ b/content/reference-rippled.md
--- a/content/reference-transaction-format.md
+++ b/content/reference-transaction-format.md
@@ -9,7 +9,7 @@ A _Transaction_ is the only way to modify the XRP Ledger. Transactions are only
 * [Transaction Results - How to find and interpret transaction results](#transaction-results)
 * [Full Transaction Response List - Complete table of all error codes](#full-transaction-response-list)

-## Authorizing Transactions ##
+## Authorizing Transactions

 In the decentralized XRP Ledger, a digital signature proves that a transaction is authorized to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction. <!-- STYLE_OVERRIDE: is authorized to -->

@@ -25,7 +25,7 @@ Any signature type can authorize any type of transaction, with the following exc
 * Only the master key can [permanently give up the ability to freeze](concept-freeze.html#no-freeze).
 * You can never remove the last method of signing transactions from an address.

-## Signing and Submitting Transactions ##
+## Signing and Submitting Transactions

 Sending a transaction to the XRP Ledger involves several steps:

@@ -36,7 +36,7 @@ Sending a transaction to the XRP Ledger involves several steps:
 5. The `rippled` servers apply those transactions to the previous ledger in a canonical order and share their results.
 6. If enough [trusted validators](tutorial-rippled-setup.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](#transaction-results) in that ledger are immutable.

-### Unsigned Transaction Format ###
+### Unsigned Transaction Format

 Here is an example of an unsigned [Payment transaction][] in JSON:

@@ -168,7 +168,7 @@ Example response from the `tx` command:
 ```


-### Multi-Signing ###
+### Multi-Signing

 Multi-signing in the XRP Ledger is the act of [authorizing transactions](#authorizing-transactions) for the XRP Ledger by using a combination of multiple secret keys. You can have any combination of authorization methods enabled for your address, including multi-signing, a master key, and a [regular key](#setregularkey). (The only requirement is that _at least one_ method must be enabled.)

@@ -188,7 +188,7 @@ To successfully submit a multi-signed transaction, you must do all of the follow
 For more information, see [How to Multi-Sign](tutorial-multisign.html).


-### Reliable Transaction Submission ###
+### Reliable Transaction Submission

 Reliably submitting transactions is the process of achieving both of the following:

@@ -205,13 +205,13 @@ To have both qualities when submitting a transaction, an application should:

 Main article: [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html)

-### Identifying Transactions ###
+### Identifying Transactions

 The `"hash"` is the unique value that identifies a particular transaction. The server provides the hash in the response when you submit the transaction; you can also look up a transaction in an account's transaction history with the [account_tx command](reference-rippled.html#account-tx).

 The transaction hash can be used as a "proof of payment" since anyone can [look up the transaction by its hash](#looking-up-transaction-results) to verify its final status.

-## Common Fields ##
+## Common Fields

 [Internal Type]: https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/SField.cpp

@@ -241,7 +241,7 @@ Every transaction type has the same set of fundamental fields. Field names are c
 [Sequence]: #canceling-or-skipping-a-transaction
 [Signers]: #signers-field

-### Auto-fillable Fields ###
+### Auto-fillable Fields

 Some fields can be automatically filled in before the transaction is signed, either by a `rippled` server or by the library used for offline signing. Both [ripple-lib](https://github.com/ripple/ripple-lib) and `rippled` can automatically provide the following values:

@@ -253,7 +253,7 @@ For a production system, we recommend *not* leaving these fields to be filled by
 The [`Paths` field](#paths) of the [Payment](#payment) transaction type can also be automatically filled in.


-### Transaction Cost ###
+### Transaction Cost

 To protect the XRP Ledger from being disrupted by spam and denial-of-service attacks, each transaction must destroy a small amount of XRP. This _[transaction cost](concept-transaction-cost.html)_ is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network.

@@ -262,7 +262,7 @@ The `Fee` field specifies an amount, in [drops of XRP][Currency Amount], to dest
 **Note:** [Multi-signed transactions](#multi-signing) require additional fees to relay to the network.


-### Canceling or Skipping a Transaction ###
+### Canceling or Skipping a Transaction

 An important and intentional feature of the XRP Ledger is that a transaction is final as soon as it has been incorporated in a validated ledger.

@@ -274,13 +274,13 @@ This approach is preferable to renumbering and resubmitting transactions 12 and

 In this way, an AccountSet transaction with no options is the canonical "[no-op](http://en.wikipedia.org/wiki/NOP)" transaction.

-### LastLedgerSequence ###
+### LastLedgerSequence

 We strongly recommend that you specify the `LastLedgerSequence` parameter on every transaction. Provide a value of about 3 higher than [the most recent ledger index](reference-rippled.html#ledger) to ensure that your transaction is either validated or rejected within a matter of seconds.

 Without the `LastLedgerSequence` parameter, a transaction can become stuck in an undesirable state where it is neither validated nor rejected for a long time. Specifically, if the load-based [transaction cost](#transaction-cost) of the network increases after you send a transaction, your transaction may not get propagated enough to be included in a validated ledger, but you would have to pay the (increased) transaction cost to [send another transaction canceling it](#canceling-or-skipping-a-transaction). Later, if the transaction cost decreases again, the transaction can become included in a future ledger. The `LastLedgerSequence` places a hard upper limit on how long the transaction can wait to be validated or rejected.

-### AccountTxnID ###
+### AccountTxnID

 The `AccountTxnID` field lets you chain your transactions together, so that a current transaction is not valid unless the previous one (by Sequence Number) is also valid and matches the transaction you expected.

@@ -288,7 +288,7 @@ One situation in which this is useful is if you have a primary system for submit

 To use AccountTxnID, you must first set the [asfAccountTxnID](#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction.

-### Memos ###
+### Memos

 The `Memos` field includes arbitrary messaging data with the transaction. It is presented as an array of objects. Each object has only one field, `Memo`, which in turn contains another object with *one or more* of the following fields:

@@ -321,7 +321,7 @@ Example of a transaction with a Memos field:
 }
 ```

-### Signers Field ###
+### Signers Field

 The `Signers` field contains a [multi-signature](#multi-signing), which has signatures from up to 8 key pairs, that together should authorize the transaction. The `Signers` list is an array of objects, each with one field, `Signer`. The `Signer` field has the following nested fields:

@@ -337,7 +337,7 @@ Because signature verification is a compute-intensive task, multi-signed transac



-### Flags ###
+### Flags

 The `Flags` field can contain various options that affect how a transaction should behave. The options are represented as binary values that can be combined with bitwise-or operations to set multiple flags at once.

@@ -381,7 +381,7 @@ _Pseudo-Transactions_ that are not created and submitted in the usual way, but m
 * [EnableAmendment - Apply a change to transaction processing](#enableamendment)


-## AccountSet ##
+## AccountSet

 [[Source]<br>](https://github.com/ripple/rippled/blob/f65cea66ef99b1de149c02c15f06de6c61abf360/src/ripple/app/transactors/SetAccount.cpp "Source")

@@ -415,7 +415,7 @@ Example AccountSet:

 If none of these options are provided, then the AccountSet transaction has no effect (beyond destroying the transaction cost). See [Canceling or Skipping a Transaction](#canceling-or-skipping-a-transaction) for more details.

-### Domain ###
+### Domain

 The `Domain` field is represented as the hex string of the lowercase ASCII of the domain. For example, the domain *example.com* would be represented as `"6578616d706c652e636f6d"`.

@@ -423,7 +423,7 @@ To remove the `Domain` field from an account, send an AccountSet with the Domain

 Client applications can use the [ripple.txt](https://wiki.ripple.com/Ripple.txt) file hosted by the domain to confirm that the account is actually operated by that domain.

-### AccountSet Flags ###
+### AccountSet Flags

 There are several options which can be either enabled or disabled for an account. Account options are represented by different types of flags depending on the situation:

@@ -463,7 +463,7 @@ The following [Transaction flags](#flags), specific to the AccountSet transactio



-#### Blocking Incoming Transactions ####
+#### Blocking Incoming Transactions

 Incoming transactions with unclear purposes may be an inconvenience for financial institutions, who would have to recognize when a customer made a mistake, and then potentially refund accounts or adjust balances depending on the mistake. The `asfRequireDest` and `asfDisallowXRP` flags are intended to protect users from accidentally sending funds in a way that is unclear about the reason the funds were sent.

@@ -471,7 +471,7 @@ For example, a destination tag is typically used to identify which hosted balanc

 You can protect against unwanted incoming payments for non-XRP currencies by not creating trust lines in those currencies. Since XRP does not require trust, the `asfDisallowXRP` flag is used to discourage users from sending XRP to an account. However, this flag is not enforced in `rippled` because it could potentially cause accounts to become unusable. (If an account did not have enough XRP to send a transaction that disabled the flag, the account would be completely unusable.) Instead, client applications should disallow or discourage XRP payments to accounts with the `asfDisallowXRP` flag enabled.

-### TransferRate ###
+### TransferRate

 The TransferRate field specifies a fee to charge whenever counterparties transfer the currency you issue. See [Transfer Fees](concept-transfer-fees.html) for more information.

@@ -479,7 +479,7 @@ In `rippled`'s WebSocket and JSON-RPC APIs, the TransferRate is represented as a



-## EscrowCancel ##
+## EscrowCancel

 [[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/Escrow.cpp "Source")

@@ -510,7 +510,7 @@ Any account may submit an EscrowCancel transaction.



-## EscrowCreate ##
+## EscrowCreate

 [[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/Escrow.cpp "Source")

@@ -548,7 +548,7 @@ Either `CancelAfter` or `FinishAfter` must be specified. If both are included, t



-## EscrowFinish ##
+## EscrowFinish

 [[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/Escrow.cpp "Source")

@@ -586,7 +586,7 @@ Any account may submit an EscrowFinish transaction.



-## OfferCancel ##
+## OfferCancel

 [[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CancelOffer.cpp "Source")

@@ -614,7 +614,7 @@ The OfferCancel method returns [tesSUCCESS](#transaction-results) even if it did



-## OfferCreate ##
+## OfferCreate

 [[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CreateOffer.cpp "Source")

@@ -644,7 +644,7 @@ An OfferCreate transaction is effectively a [limit order](http://en.wikipedia.or
 | TakerGets                 | [Currency Amount][] | Amount            | The amount and type of currency being provided by the offer creator. |
 | TakerPays                 | [Currency Amount][] | Amount            | The amount and type of currency being requested by the offer creator. |

-### Lifecycle of an Offer ###
+### Lifecycle of an Offer

 When an OfferCreate transaction is processed, it automatically consumes matching or crossing offers to the extent possible. (If existing offers provide a better rate than requested, the offer creator could pay less than the full `TakerGets` amount to receive the entire `TakerPays` amount.) If that does not completely fulfill the `TakerPays` amount, then the offer becomes an Offer object in the ledger. (You can use [OfferCreate Flags](#offercreate-flags) to modify this behavior.)

@@ -670,14 +670,14 @@ An unfunded offer can stay on the ledger indefinitely, but it does not have any
 * An offer is found to be unfunded during transaction processing, typically because it was at the tip of the orderbook.
    * This includes cases where one side or the other of an offer is found to be closer to 0 than `rippled`'s precision supports.

-#### Tracking Unfunded Offers ####
+#### Tracking Unfunded Offers

 Tracking the funding status of all offers can be computationally taxing. In particular, addresses that are actively trading may have a large number of offers open. A single balance can affect the funding status of many offers to buy different currencies. Because of this, `rippled` does not proactively find and remove offers.

 A client application can locally track the funding status of offers. To do this, first retreive an order book using the [`book_offers` command](reference-rippled.html#book-offers) and check the `taker_gets_funded` field of offers. Then,  [subscribe](reference-rippled.html#subscribe) to the `transactions` stream and watch the transaction metadata to see which offers are modified.


-### Offers and Trust ###
+### Offers and Trust

 The limit values of trust lines (See [TrustSet](#trustset)) do not affect offers. In other words, you can use an offer to acquire more than the maximum amount you trust an issuer to redeem.

@@ -685,7 +685,7 @@ However, holding non-XRP balances still requires a trust line to the address iss

 A trust line indicates an issuer you trust enough to accept their issuances as payment, within limits. Offers are explicit instructions to acquire certain issuances, so they are allowed to go beyond those limits.

-### Offer Preference ###
+### Offer Preference

 Existing offers are grouped by exchange rate (sometimes called "offer quality"), which is measured as the ratio between `TakerGets` and `TakerPays`. Offers with a higher exchange rate are taken preferentially. (That is, the person accepting the offer receives as much as possible for the amount of currency they pay out.) Offers with the same exchange rate are taken on the basis of which offer was placed in the earliest ledger version.

@@ -704,7 +704,7 @@ The `TickSize` does not affect the part of an Offer that can be executed immedia
 When an issuer enables, disables, or changes the `TickSize`, Offers that were placed under the previous setting are unaffected.


-### Expiration ###
+### Expiration

 Since transactions can take time to propagate and confirm, the timestamp of a ledger is used to determine offer validity. An offer only expires when its Expiration time is before the most-recently validated ledger. In other words, an offer with an `Expiration` field is still considered "active" if its expiration time is later than the timestamp of the most-recently validated ledger, regardless of what your local clock says.

@@ -714,7 +714,7 @@ 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 but still results in a `tesSUCCESS` transaction code. (This is because such a transaction could still successfully cancel another offer.)

-### Auto-Bridging ###
+### 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.

@@ -723,7 +723,7 @@ Example: _Anita places an offer to sell GBP and buy BRL. She might find that thi
 Auto-bridging happens automatically on any OfferCreate transaction. [Payment transactions](#payment) _do not_ autobridge by default, but path-finding can find paths that have the same effect.


-### OfferCreate Flags ###
+### OfferCreate Flags

 Transactions of the OfferCreate type support additional values in the [`Flags` field](#flags), as follows:

@@ -742,7 +742,7 @@ The following invalid flag combination prompts a `temINVALID_FLAG` error:



-## Payment ##
+## Payment
 [[Source]<br>](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/transactors/Payment.cpp "Source")

 A Payment transaction represents a transfer of value from one account to another. (Depending on the path taken, this can involve additional exchanges of value, which occur atomically.)
@@ -777,7 +777,7 @@ Example payment:
 | SendMax        | [Currency Amount][]  | Amount            | _(Optional)_ Highest amount of source currency this transaction is allowed to cost, including [transfer fees](concept-transfer-fees.html), exchange rates, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). Does not include the [XRP destroyed as a cost for submitting the transaction](#transaction-cost). For non-XRP amounts, the nested field names MUST be lower-case. Must be supplied for cross-currency/cross-issue payments. Must be omitted for XRP-to-XRP payments. |
 | DeliverMin     | [Currency Amount][]  | Amount            | _(Optional)_ Minimum amount of destination currency this transaction should deliver. Only valid if this is a [partial payment](#partial-payments). For non-XRP amounts, the nested field names are lower-case. |

-### Special issuer Values for SendMax and Amount ###
+### Special issuer Values for SendMax and Amount

 Most of the time, the `issuer` field of a non-XRP [Currency Amount][] indicates a financial institution's [issuing address](concept-issuing-and-operational-addresses.html). However, when describing payments, there are special rules for the `issuer` field in the `Amount` and `SendMax` fields of a payment.

@@ -785,13 +785,13 @@ Most of the time, the `issuer` field of a non-XRP [Currency Amount][] indicates
 * When the `issuer` field of the destination `Amount` field matches the `Destination` address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all addresses to which the destination has extended trust lines, as well as issuances created by the destination which are held on other trust lines.
 * When the `issuer` field of the `SendMax` field matches the source account's address, it is treated as a special case meaning "any issuer that the source can use." This includes creating new issuances on trust lines that other accounts have extended to the source account, and sending issuances the source account holds from other issuers.

-### Creating Accounts ###
+### Creating Accounts

 The Payment transaction type is the only way to create new accounts in the XRP Ledger. To do so, send an amount of XRP that is equal or greater than the [account reserve](concept-reserves.html) to a mathematically-valid account address that does not exist yet. When the Payment is processed, a new [AccountRoot object](reference-ledger-format.html#accountroot) is added to the ledger.

 If you send an insufficient amount of XRP, or any other currency, the Payment fails.

-### Paths ###
+### Paths

 If present, the `Paths` field must contain a _path set_ - an array of path arrays. Each individual path represents one way value can flow from the sender to receiver through various intermediary accounts and order books. A single transaction can potentially use multiple paths, for example if the transaction exchanges currency using several different order books to achieve the best rate.

@@ -806,7 +806,7 @@ The `Paths` field must not be an empty array, nor an array whose members are all

 For more information, see [Paths](concept-paths.html).

-### Payment Flags ###
+### Payment Flags

 Transactions of the Payment type support additional values in the [`Flags` field](#flags), as follows:

@@ -827,7 +827,7 @@ The [`delivered_amount`](#delivered-amount) field of a payment's metadata indica
 For more information, see the full article on [Partial Payments](concept-partial-payments.html).


-### Limit Quality ###
+### Limit Quality

 The XRP Ledger defines the "quality" of a currency exchange as the ratio of the numeric amount in to the numeric amount out. For example, if you spend $2 USD to receive £1 GBP, then the "quality" of that exchange is `0.5`.

@@ -966,7 +966,7 @@ Example PaymentChannelFund:



-## SetRegularKey ##
+## SetRegularKey

 [[Source]<br>](https://github.com/ripple/rippled/blob/4239880acb5e559446d2067f00dabb31cf102a23/src/ripple/app/transactors/SetRegularKey.cpp "Source")

@@ -996,7 +996,7 @@ For even greater security, you can use [multi-signing](#multi-signing), but mult



-## SignerListSet ##
+## SignerListSet
 [[Source]<br>](https://github.com/ripple/rippled/blob/ef511282709a6a0721b504c6b7703f9de3eecf38/src/ripple/app/tx/impl/SetSignerList.cpp "Source")

 The SignerListSet transaction creates, replaces, or removes a list of signers that can be used to [multi-sign](#multi-signing) a transaction. This transaction type was introduced by the [MultiSign amendment](concept-amendments.html#multisign). [New in: rippled 0.31.0][]
@@ -1048,7 +1048,7 @@ You cannot remove the last method of signing transactions from an account. If an



-## TrustSet ##
+## TrustSet

 [[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/SetTrust.cpp "Source")

@@ -1079,7 +1079,7 @@ Create or modify a trust line linking two accounts.
 | QualityIn                    | Unsigned Integer | UInt32            | _(Optional)_ Value incoming balances on this trust line at the ratio of this number per 1,000,000,000 units. A value of `0` is shorthand for treating balances at face value. |
 | QualityOut                   | Unsigned Integer | UInt32            | _(Optional)_ Value outgoing balances on this trust line at the ratio of this number per 1,000,000,000 units. A value of `0` is shorthand for treating balances at face value. |

-### Trust Limits ###
+### Trust Limits

 All balances on the XRP Ledger, except for XRP, represent value owed in the world outside the XRP Ledger. The address that issues those funds in the XRP Ledger (identified by the `issuer` field of the `LimitAmount` object) is expected to pay the balance back, outside of the XRP Ledger, when users redeem their XRP Ledger balances by returning them to the issuer.

@@ -1095,7 +1095,7 @@ The default state of all flags is off, except for the [NoRipple flag](concept-no

 The Auth flag of a trust line does not determine whether the trust line counts towards its owner's XRP reserve requirement. However, an enabled Auth flag prevents the trust line from being in its default state. An authorized trust line can never be deleted. An issuer can pre-authorize a trust line with the `tfSetfAuth` flag only, even if the limit and balance of the trust line are 0.

-### TrustSet Flags ###
+### TrustSet Flags

 Transactions of the TrustSet type support additional values in the [`Flags` field](#flags), as follows:

@@ -1110,7 +1110,7 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel



-# Pseudo-Transactions #
+# Pseudo-Transactions

 Pseudo-Transactions are never submitted by users, nor propagated through the network. Instead, a server may choose to inject them in a proposed ledger directly. If enough servers inject an equivalent pseudo-transaction for it to pass consensus, then it becomes included in the ledger, and appears in ledger data thereafter.

@@ -1126,7 +1126,7 @@ Some of the fields that are mandatory for normal transactions do not make sense



-## EnableAmendment ##
+## EnableAmendment

 Tracks the progress of the [amendment process](concept-amendments.html#amendment-process) for changes in transaction processing. This can indicate that a proposed amendment gained or lost majority approval, or that an amendment has been enabled.

@@ -1137,7 +1137,7 @@ Tracks the progress of the [amendment process](concept-amendments.html#amendment
 | Amendment      | String    | Hash256           | A unique identifier for the amendment. This is not intended to be a human-readable name. See [Amendments](concept-amendments.html) for a list of known amendments. |
 | LedgerSequence | Number    | UInt32            | The index of the ledger version where this amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |

-### EnableAmendment Flags ###
+### EnableAmendment Flags

 The `Flags` value of the EnableAmendment pseudo-transaction indicates the status of the amendment at the time of the ledger including the pseudo-transaction.

@@ -1150,7 +1150,7 @@ A `Flags` value of `0` (no flags) indicates that the amendment has been enabled,



-## SetFee ##
+## SetFee

 A change in [transaction cost](concept-transaction-cost.html) or [account reserve](concept-reserves.html) requirements as a result of [Fee Voting](concept-fee-voting.html).

@@ -1184,9 +1184,9 @@ A change in [transaction cost](concept-transaction-cost.html) or [account reserv



-# Transaction Results #
+# Transaction Results

-## Immediate Response ##
+## Immediate Response

 The response from the [`submit` command](reference-rippled.html#submit) contains a provisional result from the `rippled` server indicating what happened during local processing of the transaction.

@@ -1208,7 +1208,7 @@ If nothing went wrong when submitting and applying the transaction locally, the

 **Note:** A successful result at this stage does not indicate that the transaction has completely succeeded; only that it was successfully applied to the provisional version of the ledger kept by the local server. See [Finality of Results](#finality-of-results) for details.

-## Looking up Transaction Results ##
+## Looking up Transaction Results

 To see the final result of a transaction, use the [`tx` command](reference-rippled.html#tx), [`account_tx` command](reference-rippled.html#account-tx), or other response from `rippled`. Look for `"validated": true` to indicate that this response uses a ledger version that has been validated by consensus.

@@ -1226,7 +1226,7 @@ To see the final result of a transaction, use the [`tx` command](reference-rippl
    "validated": true
 ```

-## Result Categories ##
+## Result Categories

 Both the `engine_result` and the `meta.TransactionResult` use standard codes to identify the results of transactions, as follows:

@@ -1243,7 +1243,7 @@ The distinction between a local error (`tel`) and a malformed transaction (`tem`

 By contrast, a `tem` error implies that no server anywhere can apply the transaction, regardless of settings. Either the transaction breaks the rules of the protocol, it is unacceptably ambiguous, or it is completely nonsensical. The only way a malformed transaction could become valid is through changes in the protocol; for example, if a new feature is adopted, then transactions using that feature could be considered malformed by servers that are running older software which predates that feature.

-## Claimed Cost Justification ##
+## Claimed Cost Justification

 Although it may seem unfair to charge a [transaction cost](concept-transaction-cost.html) for a failed transaction, the `tec` class of errors exists for good reasons:

@@ -1251,7 +1251,7 @@ Although it may seem unfair to charge a [transaction cost](concept-transaction-c
 * Distributing the transaction throughout the network increases network load. Enforcing a cost makes it harder for attackers to abuse the network with failed transactions.
 * The transaction cost is generally very small in real-world value, so it should not harm users unless they are sending large quantities of transactions.

-## Finality of Results ##
+## Finality of Results

 The order in which transactions apply to the consensus ledger is not final until a ledger is closed and the exact transaction set is approved by the consensus process. A transaction that succeeded initially could still fail, and a transaction that failed initially could still succeed. Additionally, a transaction that was rejected by the consensus process in one round could achieve consensus in a later round.

@@ -1271,7 +1271,7 @@ Any other transaction result is potentially not final. In that case, the transac



-## Understanding Transaction Metadata ##
+## Understanding Transaction Metadata

 The metadata section of a transaction includes detailed information about all the changes to the shared XRP Ledger that the transaction caused. This is true of any transaction that gets included in a ledger, whether or not it is successful. Naturally, the changes are only final if the transaction is validated.

@@ -1285,7 +1285,7 @@ Some fields that may appear in transaction metadata include:
 | `TransactionResult`                   | String              | A [result code](#result-categories) indicating whether the transaction succeeded or how it failed. |
 | [`delivered_amount`](#delivered-amount) | [Currency Amount][] | The [Currency Amount][] actually received by the `Destination` account. Use this field to determine how much was delivered, regardless of whether the transaction is a [partial payment](#partial-payments). [New in: rippled 0.27.0][] |

-### delivered_amount ###
+### delivered_amount

 The `Amount` of a [Payment transaction][] indicates the amount to deliver to the `Destination`, so if the transaction was successful, then the destination received that much -- **except if the transaction was a [partial payment](#partial-payments)**. (In that case, any positive amount up to `Amount` might have arrived.) Rather than choosing whether or not to trust the `Amount` field, you should use the `delivered_amount` field of the metadata to see how much actually reached its destination.

@@ -1298,12 +1298,12 @@ If both conditions are true, then `delivered_amount` contains the string value `

 See also: [Partial Payments](concept-partial-payments.html)

-## Full Transaction Response List ##
+## Full Transaction Response List

 [[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/TER.h "Source")


-### tel Codes ###
+### tel Codes

 These codes indicate an error in the local server processing the transaction; it is possible that another server with a different configuration or load level could process the transaction successfully. They have numerical values in the range -399 to -300. The exact code for any given error is subject to change, so don't rely on it.

@@ -1323,7 +1323,7 @@ These codes indicate an error in the local server processing the transaction; it
 | `telLOCAL_ERROR`        | Unspecified local error.                             |
 | `telNO_DST`_`PARTIAL`   | The transaction is an XRP payment that would fund a new account, but the [tfPartialPayment flag](#partial-payments) was enabled. This is disallowed. |

-### tem Codes ###
+### tem Codes

 These codes indicate that the transaction was malformed, and cannot succeed according to the XRP Ledger protocol. They have numerical values in the range -299 to -200. The exact code for any given error is subject to change, so don't rely on it.

@@ -1364,7 +1364,7 @@ These codes indicate that the transaction was malformed, and cannot succeed acco
 | `temDISABLED`                  | The transaction requires logic that is disabled. Typically this means you are trying to use an [amendment](concept-amendments.html) that is not enabled for the current ledger. |


-### tef Codes ###
+### tef Codes

 These codes indicate that the transaction failed and was not included in a ledger, but the transaction could have succeeded in some theoretical ledger. Typically this means that the transaction can no longer succeed in any future ledger. They have numerical values in the range -199 to -100. The exact code for any given error is subject to change, so don't rely on it.

@@ -1389,7 +1389,7 @@ These codes indicate that the transaction failed and was not included in a ledge
 | `tefPAST_SEQ`           | The sequence number of the transaction is lower than the current sequence number of the account sending the transaction. |
 | `tefWRONG_PRIOR`        | The transaction contained an `AccountTxnID` field (or the deprecated `PreviousTxnID` field), but the transaction specified there does not match the account's previous transaction. |

-### ter Codes ###
+### ter Codes

 These codes indicate that the transaction failed, but it could apply successfully in the future, usually if some other hypothetical transaction applies first. They have numerical values in the range -99 to -1. The exact code for any given error is subject to change, so don't rely on it.

@@ -1407,7 +1407,7 @@ These codes indicate that the transaction failed, but it could apply successfull
 | `terRETRY`         | Unspecified retriable error.                              |
 | `terQUEUED`        | The transaction met the load-scaled [transaction cost](concept-transaction-cost.html) but did not meet the open ledger requirement, so the transaction has been queued for a future ledger. |

-### tes Success ###
+### tes Success

 The code `tesSUCCESS` is the only code that indicates a transaction succeeded. This does not always mean it did what it was supposed to do. (For example, an [OfferCancel][] can "succeed" even if there is no offer for it to cancel.) Success uses the numerical value 0.

@@ -1415,7 +1415,7 @@ The code `tesSUCCESS` is the only code that indicates a transaction succeeded. T
 |:-----------|:----------------------------------------------------------------|
 | `tesSUCCESS` | The transaction was applied and forwarded to other servers. If this appears in a validated ledger, then the transaction's success is final. |

-### tec Codes ###
+### tec Codes

 These codes indicate that the transaction failed, but it was applied to a ledger to apply the [transaction cost](concept-transaction-cost.html). They have numerical values in the range 100 to 199. The exact codes sometimes appear in ledger data, so they do not change, but we recommend not relying on the numeric value regardless.

--- a/content/tutorial-gateway-guide.md
+++ b/content/tutorial-gateway-guide.md
@@ -9,7 +9,7 @@
 This document explains the concepts and steps necessary to become an XRP Ledger gateway. In this document, we use a fictional online currency exchange named "ACME" and its customers as examples, to show how ACME can expand its business to include being an XRP Ledger gateway.


-## Contact Information ##
+## Contact Information

 You are not on your own. Ripple wants gateways to succeed, so we are here to help. Please contact us if you need help building and growing your gateway.

@@ -32,7 +32,7 @@ The XRP Ledger has a system of directional accounting relationships, called _tru
 A "trust line" is link between two addresses in the XRP Ledger. A trust line represents an explicit statement of willingness to hold gateway debt obligations. When a customer sends money into the XRP Ledger, a gateway takes custody of those assets outside of Ripple, and sends issuances in the XRP Ledger to the customer's address. When a customer sends money out of the XRP Ledger, she makes an XRP Ledger payment to the gateway, and the gateway credits the customer in its own system of record, or in some other account.


-### XRP ###
+### XRP

 **XRP** is the native cryptocurrency of the XRP Ledger. Like issuances, XRP can be freely sent and exchanged among XRP Ledger addresses. Unlike issuances, XRP is not tied to an accounting relationship. XRP can be sent directly from any XRP Ledger address to any other, without going through a gateway or liquidity provider. This helps make XRP a convenient bridge currency. For more information on XRP, see the [XRP Portal](https://ripple.com/xrp-portal/).

@@ -42,7 +42,7 @@ Issuing gateways do not need to accumulate or exchange XRP. They must only hold

 Private exchanges and liquidity providers may choose to hold additional XRP for trading. Ripple (the company) **does not** promote XRP as a speculative investment.

-### Liquidity and Currency Exchange ###
+### Liquidity and Currency Exchange

 The XRP Ledger contains a currency exchange, where any user can place and fulfill bids to exchange XRP and _issuances_ in any combination. Cross-currency payments automatically use the currency exchange to convert currency atomically when the transaction is executed. In this way, users who choose make offers in the distributed exchange provide the liquidity that makes the XRP Ledger useful.

@@ -53,7 +53,7 @@ Third-party liquidity providers can use the [`rippled` APIs](reference-rippled.h
 Contact [partners@ripple.com](mailto:partners@ripple.com) for help establishing liquidity between your gateway and others.


-## Suggested Business Practices ##
+## Suggested Business Practices

 The value of a gateway's issuances in the XRP Ledger comes directly from the trust that customers can redeem them with the gateway when needed. We recommend the following precautions to reduce the risk of business interruptions:

@@ -63,14 +63,14 @@ The value of a gateway's issuances in the XRP Ledger comes directly from the tru
 * Publicize all your policies and fees.


-### Hot and Cold Wallets ###
+### Hot and Cold Wallets

 {% include 'snippets/issuing-and-operational-addresses-intro.md' %}

 For more information, see [Issuing and Operational Addresses](concept-issuing-and-operational-addresses.html)


-## Fees and Revenue Sources ##
+## Fees and Revenue Sources

 There are several ways in which a gateway can seek to profit from XRP Ledger integration. These can include:

@@ -81,12 +81,12 @@ There are several ways in which a gateway can seek to profit from XRP Ledger int
 * [Financial Exchange](#liquidity-and-currency-exchange). A gateway can also make offers to buy and sell its issuances for other issuances in the XRP Ledger, providing liquidity to cross-currency payments and possibly making a profit. (As with all financial exchange, profits are not guaranteed.)


-### Choosing Fee Rates ###
+### Choosing Fee Rates

 Fees imposed by gateways are optional. Higher fees earn more revenue when a gateway's services are used. On the other hand, high fees discourage customers from using your services. Consider the fees that are charged by other gateways, especially ones issuing similar currencies, as well as traditional payment systems outside of the XRP Ledger, such as wire fees. Choosing the right fee structure is a matter of balancing your pricing with what the market is willing to pay.


-## Gateway Compliance ##
+## Gateway Compliance

 Gateways are responsible for complying with local regulations and reporting to the appropriate agencies. Regulations vary by country and state, but may include the reporting and compliance requirements described in the following sections.

@@ -234,7 +234,7 @@ An example flow for a payment into the XRP Ledger:



-### Requirements for Sending to XRP Ledger ###
+### Requirements for Sending to XRP Ledger

 There are several prerequisites that ACME must meet for this to happen:

@@ -252,7 +252,7 @@ There are several prerequisites that ACME must meet for this to happen:
 See [Sending Payments to Customers](#sending-payments-to-customers) for an example of how to send payments into the XRP Ledger.


-## Sending from XRP Ledger to Gateway ##
+## Sending from XRP Ledger to Gateway

 A payment out of the XRP Ledger means the Gateway receives a payment in the XRP Ledger, and credits a user in the gateway's system of record.

@@ -263,7 +263,7 @@ An example flow of a payment out of the XRP Ledger:

 Payments going from the XRP Ledger to a gateway can be single-currency or cross-currency payments. The gateway's issuing address can only receive issuances it created (or XRP).

-### Requirements for Receiving from XRP Ledger ###
+### Requirements for Receiving from XRP Ledger

 In addition to the [requirements for sending into the XRP Ledger](#requirements-for-sending-to-xrp-ledger), there are several prerequisites that ACME must meet to process payments coming from the XRP Ledger:

@@ -273,7 +273,7 @@ In addition to the [requirements for sending into the XRP Ledger](#requirements-
    - Typically, the preferred method of recognizing incoming payments is through [destination tags](#source-and-destination-tags).


-## Precautions ##
+## Precautions

 Processing payments to and from the XRP Ledger naturally comes with some risks, so a gateway should be sure to take care in implementing these processes. We recommend the following precautions:

@@ -291,7 +291,7 @@ Processing payments to and from the XRP Ledger naturally comes with some risks,
 - Monitor for suspicious or abusive behavior. For example, a user could repeatedly send funds into and out of the XRP Ledger, as a denial of service attack that effectively empties an operational address's balance. Suspend customers whose addresses are involved in suspicious behavior by not processing their XRP Ledger payments.


-## Trading on Ripple ##
+## Trading on Ripple

 After the issuances have been created in the XRP Ledger, they can be freely transferred and traded by XRP Ledger users. There are several consequences of this situation:

@@ -308,7 +308,7 @@ The following diagram depicts an XRP Ledger payment sending 2EUR.ACME from Alice



-## Freeze ##
+## Freeze

 A gateway can freeze accounting relationships in the XRP Ledger to meet regulatory requirements:

@@ -319,7 +319,7 @@ A gateway can freeze accounting relationships in the XRP Ledger to meet regulato
 For more information, see the [Freeze article](concept-freeze.html).


-## Authorized Accounts ##
+## Authorized Accounts

 The XRP Ledger's Authorized Accounts feature enables a gateway to limit who can hold that gateway's issuances, so that unknown XRP Ledger addresses cannot hold the currency the gateway issues. Ripple feels this is *not necessary* in most cases, since gateways have full control over the process of redeeming Ripple balances for value in the outside world. (You can collect customer information and impose limits on withdrawals at that stage without worrying about what happens within the XRP Ledger.)

@@ -334,7 +334,7 @@ The transaction to authorize an accounting relationship must be signed by the is
 See [RequireAuth](#requireauth) for technical details on how to use Authorized Accounts.


-## Source and Destination Tags ##
+## Source and Destination Tags

 *Destination Tags* are a feature of XRP Ledger payments can be used to indicate the beneficiary or destination for a payment. For example, an XRP Ledger payment to a gateway may include a destination tag to indicate which customer should be credited for the payment. A gateway should keep a mapping of destination tags to accounts in the gateway's system of record.

@@ -378,7 +378,7 @@ For the gateway's own security as well as the stability of the network, Ripple r

 Contact [partners@ripple.com](mailto:partners@ripple.com) to see how Ripple can help.

-### APIs and Middleware ###
+### APIs and Middleware

 There are several interfaces you can use to connect to the XRP Ledger, depending on your needs and your existing software:

@@ -386,14 +386,14 @@ There are several interfaces you can use to connect to the XRP Ledger, depending
 * [RippleAPI](reference-rippleapi.html) provides a simplified API for JavaScript applications.


-## Tool Security ##
+## Tool Security

 Any time you submit an XRP Ledger transaction, it must be signed using your secret key. The secret key gives full control over your XRP Ledger address. **Never** send your secret key to a server operated by someone else. Either use your own `rippled` server, or sign the transactions locally before sending them to a `rippled` server.

 The examples in this document show API methods that include a secret key. This is only safe if you control `rippled` server yourself, *and* you connect to it over a connection that is secure from outside listeners. (For example, you could connect over a loopback (localhost) network, a private subnet, or an encrypted VPN.) Alternatively, you could use [RippleAPI](reference-rippleapi.html) to sign transactions locally before submitting them to a third-party server.


-## DefaultRipple ##
+## DefaultRipple

 The DefaultRipple flag controls whether the balances in an accounting relationship [allowed to ripple](concept-noripple.html) by default. Rippling is what allows customers to trade issuances, so a gateway must allow rippling on all the accounting relationships to its issuing address.

@@ -452,7 +452,7 @@ Response:
 To confirm that an address has DefaultRipple enabled, look up the address using the [account_info command](reference-rippled.html#account-info), specifying a validated ledger version. Use [a bitwise-AND operator](https://en.wikipedia.org/wiki/Bitwise_operation#AND) to compare the `Flags` field with 0x00800000 (the [ledger flag lsfDefaultRipple](reference-ledger-format.html#accountroot-flags)). If the result of the bitwise-AND operation is nonzero, then the address has DefaultRipple enabled.


-## Generating Source and Destination Tags ##
+## Generating Source and Destination Tags

 You need a scheme to create Source and Destination tags for your customers and payments. (See [Source and Destination Tags](#source-and-destination-tags) for an explanation of what Source and Destination Tags are.)

@@ -465,7 +465,7 @@ We recommend making a user interface to generate a destination tag on-demand whe
 Enable the [RequireDest](#requiredest) flag on your issuing and operational addresses so that customers must use a destination tag to indicate where funds should go when they send XRP Ledger payments to your gateway.


-## DisallowXRP ##
+## DisallowXRP

 The DisallowXRP setting (`disallowIncomingXRP` in RippleAPI) is designed to discourage XRP Ledger users from sending XRP to an address by accident. This reduces the costs and effort of bouncing undesired payments, if your gateway does not trade XRP. The DisallowXRP flag is not strictly enforced, because doing so could allow addresses to become permanently unusable if they run out of XRP. Client applications should honor the DisallowXRP flag by default.

@@ -522,7 +522,7 @@ Response:
 ```


-## RequireDest ##
+## RequireDest

 The `RequireDest` setting (`requireDestinationTag` in RippleAPI) is designed to prevent customers from sending payments to your address while accidentally forgetting the [destination tag](#source-and-destination-tags) that identifies who should be credited for the payment. When enabled, the XRP Ledger rejects any payment to your address that does not specify a destination tag.

@@ -580,7 +580,7 @@ Response:
 }
 ```

-## RequireAuth ##
+## RequireAuth

 The `RequireAuth` setting (`requireAuthorization` in RippleAPI) prevents all counterparties from holding balances issued by an address unless the address has specifically approved an accounting relationship with that counterparty.

@@ -590,7 +590,7 @@ If you want to use the [Authorized Accounts](#authorized-accounts) feature, you

 You can only enable `RequireAuth` if the address owns no accounting relationships (trust lines) and no offers in the XRP Ledger, so you must decide whether or not to use it before you start doing business in the XRP Ledger.

-### Enabling RequireAuth ###
+### Enabling RequireAuth

 The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send an AccountSet transaction to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)

@@ -617,7 +617,7 @@ POST http://localhost:5005/

 {% include 'snippets/secret-key-warning.md' %}

-### Authorizing Trust Lines ###
+### Authorizing Trust Lines

 If you are using the [Authorized Accounts](#authorized-accounts) feature, customers cannot hold balances you issue unless you first authorize their accounting relationships to you in the XRP Ledger.

@@ -653,7 +653,7 @@ POST http://localhost:8088/
 {% include 'snippets/secret-key-warning.md' %}


-## Robustly Monitoring for Payments ##
+## Robustly Monitoring for Payments

 To robustly check for incoming payments, gateways should do the following:

@@ -672,7 +672,7 @@ As an added precaution, we recommend comparing the balances of your issuing addr
 * If you have a [TransferRate](#transferrate) set, then your obligations within the XRP Ledger decrease slightly whenever other XRP Ledger addresses transfer your issuances among themselves.


-## TransferRate ##
+## TransferRate

 The *TransferRate* setting (`transferRate` in RippleAPI) defines a fee to charge for transferring issuances from one XRP Ledger address to another. See [Transfer Fees](concept-transfer-fees.html) for more information.

@@ -724,7 +724,7 @@ Response:
 }
 ```

-### TransferRate with Operational and Standby Addresses ###
+### TransferRate with Operational and Standby Addresses

 All XRP Ledger addresses, including operational and standby addresses, are subject to the transfer fee. If you set a nonzero transfer fee, then you must send extra (to pay the TransferRate) when making payments from your operational address or standby address. In other words, your addresses must pay back a little of the balance your issuing address created, each time you make a payment.

@@ -736,7 +736,7 @@ All XRP Ledger addresses, including operational and standby addresses, are subje
 For example: If ACME sets a transfer fee of 1%, an XRP Ledger payment to deliver 5 EUR.ACME from a customer address to ACME's issuing address would cost exactly 5 EUR.ACME. However, the customer would need to send 5.05 EUR.ACME to deliver 5 EUR.ACME to ACME's operational address. (The issuing address's total obligations in the XRP Ledger decrease by 0.05 EUR.ACME.) When ACME credits customers for payments to ACME's operational address, ACME credits the customer for the amount delivered to the operational address _and_ the transfer fee, giving the customer €5,05 in ACME's systems.


-## Sending Payments to Customers ##
+## Sending Payments to Customers

 When you build an automated system to send payments into the XRP Ledger for your customers, you must make sure that it constructs payments carefully. Malicious actors are constantly trying to find ways to trick a system into paying them more money than it should.

@@ -815,7 +815,7 @@ In particular, note the following features of the [Payment Transaction](referenc
 - The `value` of the `SendMax` amount is slightly higher than the destination `Amount`, to compensate for the [transfer fee](#transferrate). In this case, the transfer fee is 0.5%, so the `SendMax` amount is exactly 1.005 times the destination `Amount`.


-## Bouncing Payments ##
+## Bouncing Payments

 When one of your addresses receives a payment whose purpose is unclear, we recommend that you try to return the money to its sender. While this is more work than pocketing the money, it demonstrates good faith towards customers. You can have an operator bounce payments manually, or create a system to do so automatically.

@@ -831,7 +831,7 @@ You should use the `SourceTag` value (`source.tag` in RippleAPI) from the incomi
 To prevent two systems from bouncing payments back and forth indefinitely, you can set a new Source Tag for the outgoing return payment. If you receive an unexpected payment whose Destination Tag matches the Source Tag of a return you sent, then do not bounce it back again.


-## Reliable Transaction Submission ##
+## Reliable Transaction Submission

 The goal of reliably submitting transactions is to achieve the following two properties in a finite amount of time:

@@ -847,7 +847,7 @@ To submit transactions reliably, follow these guidelines:
 For more information, see [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).


-## ripple.txt ##
+## ripple.txt

 The [ripple.txt](https://wiki.ripple.com/Ripple.txt) standard provides a way to publish information about your gateway so that automated tools and applications can read and understand it.

--- a/content/tutorial-multisign.md
+++ b/content/tutorial-multisign.md
@@ -1,5 +1,4 @@
-How to Multi-Sign
-=============================
+# How to Multi-Sign

 Multi-signing is one of three ways to authorize transactions for the XRP Ledger, alongside signing with [regular keys](reference-transaction-format.html#setregularkey) and master keys. You can configure your address to allow any combination of the three methods to authorize transactions.

@@ -17,8 +16,7 @@ To use multi-signing:
 3. [Send transactions using multiple signatures.](#sending-a-multi-signed-transaction)


-Availability of Multi-Signing
-----------------------------
+## Availability of Multi-Signing

 Multi-signing has been enabled by an [**Amendment**](concept-amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27.

@@ -30,13 +28,12 @@ To force the multi-signing feature to be enabled, add the following stanza to yo
    MultiSign


-Setting up Multi-Signing
------------------------
+## Setting up Multi-Signing

 To multi-sign transactions from a particular address, you must create a list of addresses that can contribute to a multi-signature for your address. This list is stored in the XRP Ledger as a [SignerList node](reference-ledger-format.html#signerlist). The following procedure demonstrates how to set up a SignerList for your address:


-### 1. Prepare a funded address ###
+### 1. Prepare a funded address

 You need an XRP Ledger address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the [account reserve](concept-reserves.html) and [transaction cost](concept-transaction-cost.html), increasing with the number of signers and signatures you use.

@@ -47,7 +44,7 @@ If you started `rippled` in [stand-alone mode](concept-stand-alone-mode.html) wi
 3. Manually close the ledger.


-### 2. Prepare member keys ###
+### 2. Prepare member keys

 You need several sets of XRP Ledger keys (address and secret) to include as members of your SignerList. These can be funded addresses that exist in the ledger, or you can generate new addresses using the [`wallet_propose` command](reference-rippled.html#wallet-propose). For example:

@@ -70,7 +67,7 @@ You need several sets of XRP Ledger keys (address and secret) to include as memb
 Take note of the `account_id` (XRP Ledger Address) and `master_seed` (secret key) for each one you generate.


-### 3. Send SignerListSet transaction ###
+### 3. Send SignerListSet transaction

 [Sign and submit](reference-transaction-format.html#signing-and-submitting-transactions) a [SignerListSet transaction](reference-transaction-format.html#signerlistset) in the normal (single-signature) way. This associates a SignerList with your XRP Ledger address, so that a combination of signatures from the members of that SignerList can multi-sign later transactions on your behalf.

@@ -153,7 +150,7 @@ Make sure that the [Transaction Result](reference-transaction-format.html#transa
 **Note:** The more members in the SignerList, the more XRP your address must have for purposes of the [owner reserve](concept-reserves.html#owner-reserves). If your address does not have enough XRP, the transaction fails with [tecINSUFFICIENT_RESERVE](reference-transaction-format.html#tec-codes). See also: [SignerLists and Reserves](reference-ledger-format.html#signerlists-and-reserves).


-### 4. Close the ledger ###
+### 4. Close the ledger

 On the live network, you can wait 4-7 seconds for the ledger to close automatically.

@@ -170,7 +167,7 @@ If you're running `rippled` in stand-alone mode, use the [`ledger_accept` comman
    }


-### 5. Confirm the new signer list ###
+### 5. Confirm the new signer list

 Use the [`account_objects` command](reference-rippled.html#account-objects) to confirm that the SignerList is associated with the address in the latest validated ledger.

@@ -223,7 +220,7 @@ Normally, an account can own many objects of different types (such as trust line

 If the SignerList is present with the expected contents, then your address is ready to multi-sign.

-### 6. Further steps ###
+### 6. Further steps

 At this point, your address is ready to [send a multi-signed transaction](#sending-a-multi-signed-transaction). You may also want to:

@@ -231,12 +228,11 @@ At this point, your address is ready to [send a multi-signed transaction](#sendi
 * Remove the address's regular key pair (if you previously set one) by sending a [SetRegularKey transaction](reference-transaction-format.html#setregularkey).


-Sending a Multi-Signed Transaction
----------------------------------
+## Sending a Multi-Signed Transaction

 Before you can multi-sign a transaction, first  [set up multi-signing](#setting-up-multi-signing) for your address. The following procedure demonstrates how to create, sign, and submit a multi-signed transaction.

-### 1. Create the transaction ##
+### 1. Create the transaction

 Create a JSON object that represents the transaction you want to submit. You have to specify _everything_ about this transaction, including `Fee` and `Sequence`. Also include the field `SigningPubKey` as an empty string, to indicate that the transaction is multi-signed.

@@ -261,7 +257,7 @@ Here's an example transaction ready to be multi-signed:
 (This transaction creates an accounting relationship from rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC to rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh with a maximum balance of 100 USD.)


-### 2. Get one signature ###
+### 2. Get one signature

 Use the [`sign_for` command](reference-rippled.html#sign-for) with the secret key and address of one of the members of your SignerList to get a signature for that member.

@@ -316,7 +312,7 @@ Save the `tx_json` field of the response: it has the new signature in the `Signe

 If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](#availability-of-multi-signing).

-### 3. Get additional signatures ###
+### 3. Get additional signatures

 You can collect additional signatures in parallel or in serial:

@@ -390,7 +386,7 @@ You can collect additional signatures in parallel or in serial:
 Depending on the SignerList you configured, you may need to repeat this step several times to get signatures from all the necessary parties.


-### 4. Combine signatures and submit ###
+### 4. Combine signatures and submit

 If you collected the signatures in serial, the `tx_json` from the last `sign_for` response has all the signatures assembled, so you can use that as the argument to the [`submit_multisigned` command](reference-rippled.html#submit-multisigned).

@@ -469,7 +465,7 @@ If you collected the signatures in parallel, you must manually construct a `tx_j
 Take note of the `hash` value from the response so you can check the results of the transaction later.  (In this case, the hash is `BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6`.)


-### 5. Close the ledger ##
+### 5. Close the ledger

 If you are using the live network, you can wait 4-7 seconds for the ledger to close automatically.

@@ -486,7 +482,7 @@ If you're running `rippled` in stand-alone mode, use the [`ledger_accept` comman
    }


-### 6. Confirm transaction results ###
+### 6. Confirm transaction results

 Use the hash value from the response to the `submit_multisigned` command to look up the transaction using the [`tx` command](reference-rippled.html#tx). In particular, check that the `TransactionResult` is the string `tesSUCCESS`.

--- a/content/tutorial-rippleapi-beginners-guide.md
+++ b/content/tutorial-rippleapi-beginners-guide.md
@@ -4,11 +4,11 @@ This tutorial guides you through the basics of building an XRP Ledger-connected

 The scripts and configuration files used in this guide are [available in the Ripple Dev Portal GitHub Repository](https://github.com/ripple/ripple-dev-portal/tree/master/content/code_samples/rippleapi_quickstart).

-# Environment Setup #
+# Environment Setup

 The first step to using RippleAPI is setting up your development environment.

-## Install Node.js and npm ##
+## Install Node.js and npm

 RippleAPI is built as an application for the Node.js runtime environment, so the first step is getting Node.js installed. RippleAPI requires Node.js version 0.12, version 4.x, or higher.

@@ -26,7 +26,7 @@ On some platforms, the binary is named `nodejs` instead:
 nodejs --version
 ```

-## Use NPM to install RippleAPI and dependencies ##
+## Use NPM to install RippleAPI and dependencies

 RippleAPI uses the newest version of JavaScript, ECMAScript 6 (also known as ES2015). To use the new features of ECMAScript 6, RippleAPI depends on [Babel-Node](https://babeljs.io) and its ES2015 presets. You can use `npm` to install RippleAPI and these dependencies together.

@@ -76,7 +76,7 @@ npm WARN notsup Not compatible with your operating system or architecture: fseve
 npm WARN ajv@1.4.10 requires a peer of ajv-i18n@0.1.x but none was installed.
 ```

-# First RippleAPI Script ##
+# First RippleAPI Script

 This script, `get-account-info.js`, fetches information about a hard-coded account. Use it to test that RippleAPI works:

@@ -84,7 +84,7 @@ This script, `get-account-info.js`, fetches information about a hard-coded accou
 {% include 'code_samples/rippleapi_quickstart/get-account-info.js' %}
 ```

-## Running the script ##
+## Running the script

 RippleAPI and the script both use the ECMAScript 6 version of JavaScript. That's why we installed Babel earlier. The easiest way to run ECMAScript 6 is to use the `babel-node` binary, which NPM installs in the `node_modules/.bin/` directory of your project. Thus, running the script looks like this:

@@ -106,11 +106,11 @@ getAccountInfo done
 done and disconnected.
 ```

-## Understanding the script ##
+## Understanding the script

 In addition to RippleAPI-specific code, this script uses syntax and conventions that are recent developments in JavaScript. Let's divide the sample code into smaller chunks to explain each one.

-### Script opening ###
+### Script opening

 ```
 'use strict';
@@ -119,9 +119,9 @@ const RippleAPI = require('ripple-lib').RippleAPI;

 The opening line enables [strict mode](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode). This is purely optional, but it helps you avoid some common pitfalls of JavaScript. See also: [Restrictions on Code in Strict Mode](https://msdn.microsoft.com/library/br230269%28v=vs.94%29.aspx#Anchor_1).

-The second line imports RippleAPI into the current scope using Node.js's require function. RippleAPI is one of [the modules `ripple-lib` exports](https://github.com/ripple/ripple-lib/blob/develop/src/index.js).
+The second line imports RippleAPI into the current scope using Node.js's require function. RippleAPI is one of [the modules `ripple-lib` exports](https://github.com/ripple/ripple-lib/blob/develop/src/index.ts).

-### Instantiating the API ###
+### Instantiating the API

 ```
 const api = new RippleAPI({
@@ -138,7 +138,7 @@ The one argument to the constructor is an options object, which has [a variety o
 * You can specify a [Ripple Test Net](https://ripple.com/build/ripple-test-net/) server instead to connect to the parallel-world Test Network instead of the production XRP Ledger.
 * If you [run your own `rippled`](tutorial-rippled-setup.html), you can instruct it to connect to your local server. For example, you might say `server: 'ws://localhost:5005'` instead.

-### Connecting and Promises ###
+### Connecting and Promises

 ```
 api.connect().then(() => {
@@ -152,7 +152,7 @@ When a Promise finishes with its asynchronous operations, the Promise runs the c

 Finally, we have more new ECMAScript 6 syntax - an [arrow function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions). Arrow functions are a shorter way of defining anonymous functions. This is convenient for defining lots of one-off functions as callbacks. The syntax `()=> {...}` is mostly equivalent to `function() {...}`. If you want an anonymous function with one parameter, you can use a syntax like `info => {...}` instead, which is almost the same as `function(info) {...}` syntax.

-### Custom code ###
+### Custom code

 ```
  /* begin custom code ------------------------------------ */
@@ -178,7 +178,7 @@ Keep in mind that the example code starts in the middle of a callback function (

 The `getAccountInfo` API method returns another Promise, so the line `}).then( info => {` defines another anonymous callback function to run when this Promise's asynchronous work is done. Unlike the previous case, this callback function takes one argument, called `info`, which holds the asynchronous return value from the `getAccountInfo` API method. The rest of this callback function outputs that return value to the console.

-### Cleanup ###
+### Cleanup

 ```
 }).then(() => {
@@ -192,7 +192,7 @@ The rest of the sample code is mostly more [boilerplate code](reference-rippleap

 The `catch` method ends this Promise chain. The callback provided here runs if any of the Promises or their callback functions encounters an error. In this case, we pass the standard `console.error` function, which writes to the console, instead of defining a custom callback. You could define a smarter callback function here to intelligently catch certain error types.

-# Waiting for Validation #
+# Waiting for Validation

 One of the biggest challenges in using the XRP Ledger (or any decentralized system) is knowing the final, immutable transaction results. Even if you [follow the best practices](tutorial-reliable-transaction-submission.html) you still have to wait for the [consensus process](https://ripple.com/build/ripple-ledger-consensus-process/) to finally accept or reject your transaction. The following example code demonstrates how to wait for the final outcome of a transaction:

@@ -208,11 +208,11 @@ If you are the administrator of the `rippled` server, you can [manually request

 See [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html) for a more thorough explanation.

-# RippleAPI in Web Browsers #
+# RippleAPI in Web Browsers

 RippleAPI can also be used in a web browser if you compile a browser-compatible version and include [lodash](https://www.npmjs.com/package/lodash) as a dependency before the RippleAPI script.

-## Build Instructions ##
+## Build Instructions

 To use RippleAPI in a browser, you need to build a browser-compatible version. The following process compiles RippleAPI into a single JavaScript file you can include in a webpage.

@@ -276,7 +276,7 @@ This may take a while. At the end, the build process creates a new `build/` fold

 The file `build/ripple-<VERSION NUMBER>.js` is a straight export of RippleAPI (whatever version you built) ready to be used in browsers. The file ending in `-min.js` is the same thing, but with the content [minified](https://en.wikipedia.org/wiki/Minification_%28programming%29) for faster loading.

-## Example Browser Usage ##
+## Example Browser Usage

 The following HTML file demonstrates basic usage of the browser version of RippleAPI to connect to a public `rippled` server and report information about that server. Instead of using Node.js's "require" syntax, the browser version creates a global variable named `ripple`, which contains the `RippleAPI` class.

--- a/content/tutorial-rippled-setup.md
+++ b/content/tutorial-rippled-setup.md
@@ -1,4 +1,4 @@
-# Operating rippled Servers #
+# Operating rippled Servers

 The core server of the XRP Ledger peer-to-peer network is [`rippled`](reference-rippled.html). Anyone can run their own `rippled` server that follows the network and keeps a complete copy of the XRP Ledger. You can even have your server take part in the consensus process.

@@ -8,7 +8,7 @@ This page contains instructions for:
 * [Participating in the Consensus Process](#running-a-validator)


-## Types of rippled Servers ##
+## Types of rippled Servers

 The `rippled` server software can run in several modes depending on its configuration, including:

@@ -19,7 +19,7 @@ The `rippled` server software can run in several modes depending on its configur
 You can also run the `rippled` executable as a client application for accessing [`rippled` APIs](reference-rippled.html) locally. (Two instances of the same binary can run side-by-side in this case; one as a server, and the other running briefly as a client and then terminating.)


-## Reasons to Run a Stock Server ##
+## Reasons to Run a Stock Server

 There are lots of reasons you might want to run your own `rippled` server, but most of them can be summarized as: you can trust your own server, you have control over its workload, and you're not at the mercy of others to decide when and how you can access it. Of course, you must practice good network security to protect your server from malicious hackers.

@@ -42,7 +42,7 @@ Not all `rippled` servers need to be validators: trusting more servers from the

 If your organization runs a validating server, you may also run one or more stock servers, to balance the computing load of API access, or as a proxy between your validation server and the outside network.

-### Properties of a Good Validator ###
+### Properties of a Good Validator

 There are several properties that define a good validator. The more of these properties your server embodies, the more reason others have to include your server in their list of trusted validators:

@@ -58,13 +58,13 @@ There are several properties that define a good validator. The more of these pro
 At present, Ripple (the company) cannot recommend any validators aside from the 5 core validators run by Ripple: these validators are included in the default `rippled` configuration. However, we are collecting data on other validators and building tools to report on their performance. For metrics on validators, see [validators.ripple.com](https://validators.ripple.com).


-# Installing rippled #
+# Installing rippled

 For development, you can [compile `rippled` from source](https://wiki.ripple.com/Rippled_build_instructions).

 Production `rippled` instances can [use Ripple's binary executable](#installation-on-centosred-hat-with-yum), available from the Ripple [yum](https://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified) repository.

-## System Requirements ##
+## System Requirements

 A `rippled` server should run comfortably on commodity hardware, to make it inexpensive to participate in the network. At present, we recommend the following:

@@ -80,7 +80,7 @@ Amazon EC2's m3.large VM size may be appropriate depending on your workload. (Va
 Naturally, a fast network connection is preferable.


-## Installation on CentOS/Red Hat with yum ##
+## Installation on CentOS/Red Hat with yum

 This section assumes that you are using CentOS 7 or Red Hat Enterprise Linux 7.

@@ -100,7 +100,7 @@ This section assumes that you are using CentOS 7 or Red Hat Enterprise Linux 7.

        $ sudo systemctl start rippled.service

-## Installation on Ubuntu with alien ##
+## Installation on Ubuntu with alien

 This section assumes that you are using Ubuntu 15.04 or later.

@@ -133,7 +133,7 @@ This section assumes that you are using Ubuntu 15.04 or later.

        $ sudo systemctl start rippled.service

-## Postinstall ##
+## Postinstall

 It can take several minutes for `rippled` to sync with the rest of the network, during which time it outputs warnings about missing ledgers. After that, you have a fully functional stock `rippled` server that you can use for local signing and API access to the XRP Ledger.

@@ -142,11 +142,11 @@ It can take several minutes for `rippled` to sync with the rest of the network,
        $ /opt/ripple/bin/rippled <command>


-## Updating rippled ##
+## Updating rippled

 You can subscribe to the [rippled Google Group](https://groups.google.com/forum/#!forum/ripple-server) to receive notifications of new `rippled` releases.

-### Automatic Update on CentOS/Red Hat ###
+### Automatic Update on CentOS/Red Hat

 Automatic rippled updates can be enabled with a one-time Cron configuration:

@@ -168,7 +168,7 @@ Automatic rippled updates can be enabled with a one-time Cron configuration:

 The script updates the installed `rippled` package within an hour of each new release.

-### Manual Update on CentOS/Red Hat ###
+### Manual Update on CentOS/Red Hat

 Run the following commands to update to the latest release of `rippled`:

@@ -177,7 +177,7 @@ Run the following commands to update to the latest release of `rippled`:
        $ sudo systemctl daemon-reload
        $ sudo service rippled restart

-### Manual Update on Ubuntu ###
+### Manual Update on Ubuntu

 Run the following commands to update to the latest release of `rippled`:

@@ -189,7 +189,7 @@ Run the following commands to update to the latest release of `rippled`:
        $ sudo service rippled restart


-# Running a Validator #
+# Running a Validator

 Running a `rippled` validator that participates in the Consensus process is simple:

@@ -200,7 +200,7 @@ Running a `rippled` validator that participates in the Consensus process is simp
    * Also see [Properties of a Good Validator](#properties-of-a-good-validator) for best practices.


-## Validator Setup ##
+## Validator Setup

 The `validator-keys` tool (included in the `rippled` RPM) is the recommended means to securely generate and manage your validator keys.

@@ -225,7 +225,7 @@ The `validator-keys` tool (included in the `rippled` RPM) is the recommended mea
 See [the `validator-keys-tool` GitHub repository](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md) for more information about managing validator keys.


-## Public-Facing Server ##
+## Public-Facing Server

 To protect a production validator from [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks, you can use a stock `rippled` server as a proxy between the validator and the outside network.

@@ -246,7 +246,7 @@ Remember to restart `rippled` for config changes to take effect.
 Take care not to publish the IP address of your validator.


-## Domain Verification ##
+## Domain Verification

 Network participants are unlikely to trust validators without knowing who is operating them. To address this concern, validator operators can associate their validator with a web domain that they control.

@@ -265,7 +265,7 @@ Network participants are unlikely to trust validators without knowing who is ope
 4. In order to have the verified validator domain published, email <validators@ripple.com> with both signatures as well as the validator public key and domain name.


-# Additional Configuration #
+# Additional Configuration

 `rippled` should connect to the XRP Ledger with the default configuration. However, you can change your settings by editing the `rippled.cfg` file (located at `/opt/ripple/etc/rippled.cfg` when installing `rippled` with yum).

@@ -280,7 +280,7 @@ Restart `rippled` for any configuration changes to take effect:
        $ sudo service rippled restart


-## Parallel Networks ##
+## Parallel Networks

 Most of the time, we describe the XRP Ledger as one collective, singular entity -- and that's mostly true. There is one production XRP Ledger peer-to-peer network, and all business that takes place on the XRP Ledger occurs within the production network.

@@ -290,12 +290,12 @@ However, sometimes you may want to do tests and experiments without interacting

 Over time, there may also be smaller, temporary test networks for specific purposes.

-### Parallel Networks and Consensus ###
+### 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.


-## Clustering ##
+## Clustering

 If you are running multiple `rippled` servers in a single datacenter, you can configure those servers into a cluster to maximize efficiency. Running your `rippled` servers in a cluster provides the following benefits: