Consensus diagrams: new validate diagram; queue page and diagram

content/concepts/consensus-network/consensus.md

@@ -99,12 +99,9 @@ In cases where a server is in the minority, having computed a ledger that differ
 
 If the network fails to achieve supermajority agreement on validations, this implies that transaction volume was too high or network latency too great for the consensus process to produce consistent proposals. In this case, the servers repeat the consensus process. As time passes since consensus began, it becomes increasingly likely that a majority of the servers have received the same set of candidate transactions, as each consensus round reduces disagreement. The XRP Ledger dynamically adjusts [transaction costs](transaction-cost.html) and the time to wait for consensus in response to these conditions.
 
-[![Figure 9: Network Recognizes a New Validated Ledger Version](img/consensus-validated-ledger.png)](img/consensus-validated-ledger.png)
-
-_Figure 9: Network Recognises the New Validated Ledger Version — At the end of a round of the consensus process, servers have an updated validated ledger._
-
 Once they reach supermajority agreement on validations, the servers work with the new validated ledger, sequence number N+1. The consensus and validation process repeats <a href="#footnote_10" id="footnote_from_10"><sup>10</sup></a>, considering candidate transactions that were not included in the last round along with new transactions submitted in the meantime.
 
+
 ## Key Takeaways
 
 Transactions submitted to the XRP Ledger are not processed instantaneously. For a period of time, each transaction remains a candidate.

content/concepts/consensus-network/transaction-queue.md

@@ -0,0 +1,22 @@
+# Transaction Queue
+
+The `rippled` server uses a transaction queue to help enforce the [open ledger cost](transaction-cost.html#open-ledger-cost). The open ledger cost sets a target number of transactions in a given ledger, and escalates the required transaction cost very quickly when the open ledger surpasses this size. Rather than discarding transactions that cannot pay the escalated transaction cost, `rippled` tries to put them in a transaction queue, which it uses to build the next ledger.
+
+## Order Within the Queue
+
+Within the transaction queue, transactions are ranked so that transactions paying a higher transaction cost come first. This ranking is not by the transactions' _absolute_ XRP cost, but by their _[fee levels](transaction-cost.html#fee-levels)_ which are relative to the [minimum cost for that type of transaction](transaction-cost.html#special-transaction-costs). Other factors may also affect the order of transactions in the queue; for example, transactions from the same sender are sorted by their `Sequence` numbers so that they are submitted in order.
+
+## Transaction Queue and Consensus
+
+The transaction queue plays an important role in selecting the transactions that are included or excluded from a given ledger version in the consensus process. The following steps describe how the transaction queue relates to the [consensus process](consensus.html).
+
+{% include '_snippets/consensus-q-diagram.html' %}
+<!--_ -->
+
+**Note:** Technically, several of the steps described in the above process occur in parallel, because each server is always listening for new transactions, and starts preparing its next ledger proposal while the consensus process for the previous ledger version is ongoing.
+
+## See Also
+
+- [Transaction Cost](transaction-cost.html)
+    - [Queued Transactions](transaction-cost.html#queued-transactions)
+- [Consensus](consensus.html) for a detailed description of how the consensus process approves transactions.