diff --git a/concept-transaction-cost.html b/concept-transaction-cost.html
index a21dd88c2f..9f5ab2791f 100644
--- a/concept-transaction-cost.html
+++ b/concept-transaction-cost.html
@@ -234,7 +234,7 @@
 <h3 id="queued-transactions">Queued Transactions</h3>
 <p>When <code>rippled</code> receives a transaction that meet the server's local load cost but not the <a href="#open-ledger-cost">open ledger cost</a>, 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 <a href="#transaction-costs-and-failed-transactions">the transaction cost only applies when a transaction is included in a validated ledger</a>.</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 <a href="#reference-transaction-cost">reference cost</a> of those transactions. Transactions that pay the same transaction cost are queued in the order the server receives them.</p>
-<p class="devportal-callout note"><strong>Note:</strong> When <code>rippled</code> queues a transaction, the provisional <a href="reference-transaction-format.html#transaction-results">transaction response code</a> is <code>terQUEUED</code>. This means that the transaction is likely to succeed in a future. 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 <a href="reference-transaction-format.html#finality-of-results">rendered permanently invalid</a>.</p>
+<p class="devportal-callout note"><strong>Note:</strong> When <code>rippled</code> queues a transaction, the provisional <a href="reference-transaction-format.html#transaction-results">transaction response code</a> is <code>terQUEUED</code>. 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 <a href="reference-transaction-format.html#finality-of-results">rendered permanently invalid</a>.</p>
 <h4 id="queuing-restrictions">Queuing Restrictions</h4>
 <p>The <code>rippled</code> 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:</p>
 <ul>
diff --git a/content/concept-transaction-cost.md b/content/concept-transaction-cost.md
index e91e63a22f..9254207e3d 100644
--- a/content/concept-transaction-cost.md
+++ b/content/concept-transaction-cost.md
@@ -62,7 +62,7 @@ When `rippled` receives a transaction that meet the server's local load cost but
 
 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. 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).
+**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 ####