diff --git a/concept-transaction-cost.html b/concept-transaction-cost.html
index a40c17002d..0fa0efff1b 100644
--- a/concept-transaction-cost.html
+++ b/concept-transaction-cost.html
@@ -173,7 +173,7 @@
 <ul>
 <li>Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost.</li>
 <li>Transactions that specify a transaction cost high enough to be included in the current open ledger.</li>
-<li>Transactions in between, which get <a href="#queued-transactions">queued for the next open ledger</a>.</li>
+<li>Transactions in between, which get <a href="#queued-transactions">queued for a later ledger version</a>.</li>
 </ul>
 <h2 id="local-load-cost">Local Load Cost</h2>
 <p>Each <code>rippled</code> server maintains a cost threshold based on its current load. If you submit a transaction with a <code>Fee</code> value that is lower than current load-based transaction cost of the <code>rippled</code> server, that server neither applies nor relays the transaction. (<strong>Note:</strong> If you submit a transaction through an <a href="reference-rippled.html#connecting-to-rippled">admin connection</a>, the server applies and relays the transaction as long as the transaction cost meets the overall minimum.) A transaction is very unlikely to survive <a href="https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/">the consensus process</a> unless its <code>Fee</code> value meets the requirements of a majority of servers.</p>
@@ -186,7 +186,7 @@ Transactions that do not meet the open ledger cost are <a href="#queued-transact
 <p>(Requires the <a href="concept-amendments.html#feeescalation">FeeEscalation amendment</a>)</p>
 <p>When <code>rippled</code> receives a transaction that meet the server's local load cost but not the open ledger cost, the server checks the transaction to see if it 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 minimize the amount of network load caused by transactions that would not pay a transaction cost, since <a href="#transaction-costs-and-failed-transactions">the transaction cost only applies when a transaction is included in a validated ledger</a>.</p>
 <p>The <code>rippled</code> server uses a variety of heuristics to determine which transactions are "likely to be included in a ledger."  Most importantly, those transactions must be properly-formed and <a href="reference-transaction-format.html#authorizing-transactions">authorized</a> with valid signatures.</p>
-<p>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. Transactions that pay the same transaction cost are queued in the order the server receives them.</p>
+<p>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 un-scaled cost of those transactions. Transactions that pay the same transaction cost are queued in the order the server receives them.</p>
 <p><strong>Note:</strong> As of <code>rippled</code> <strong>version 0.31.0</strong>, the transaction queue supports at most 1 transaction per sending address. This is expected to change in later versions.</p>
 <p><strong>Caution:</strong> The current implementation does not allow transactions with an <code>AccountTxnID</code> field in the transaction queue.</p>
 <h2 id="querying-the-transaction-cost">Querying the Transaction Cost</h2>
diff --git a/content/concept-transaction-cost.md b/content/concept-transaction-cost.md
index 359f19cef5..35831eec2b 100644
--- a/content/concept-transaction-cost.md
+++ b/content/concept-transaction-cost.md
@@ -38,7 +38,7 @@ This divides transactions into roughly three categories:
 
 * Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost.
 * Transactions that specify a transaction cost high enough to be included in the current open ledger.
-* Transactions in between, which get [queued for the next open ledger](#queued-transactions).
+* Transactions in between, which get [queued for a later ledger version](#queued-transactions).
 
 
 ## Local Load Cost ##
@@ -62,7 +62,7 @@ When `rippled` receives a transaction that meet the server's local load cost but
 
  The `rippled` server uses a variety of heuristics to determine which transactions are "likely to be included in a ledger."  Most importantly, those transactions must be properly-formed and [authorized](reference-transaction-format.html#authorizing-transactions) with valid signatures.
 
-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. Transactions that pay the same transaction cost are queued in the order the server receives them.
+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 un-scaled cost of those transactions. Transactions that pay the same transaction cost are queued in the order the server receives them.
 
 **Note:** As of `rippled` **version 0.31.0**, the transaction queue supports at most 1 transaction per sending address. This is expected to change in later versions.