From d4f5b1108df949ff2dfec01633a3841cf3b85f8b Mon Sep 17 00:00:00 2001 From: Fraser Waters Date: Wed, 1 Apr 2020 19:52:41 +0100 Subject: [PATCH] submit response validated_ledger_cost is an Integer not a String --- .../public-rippled-methods/transaction-methods/submit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md b/content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md index bfe5861deb..cb8587d2ec 100644 --- a/content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md +++ b/content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md @@ -297,7 +297,7 @@ The response follows the [standard format][], with a successful result containin | `kept` | Boolean | _(Omitted in sign-and-submit mode)_ The value `true` indicates that the transaction was kept to be retried later. [New in: rippled 1.5.0][] | | `queued` | Boolean | _(Omitted in sign-and-submit mode)_ The value `true` indicates the transaction was put in the [Transaction Queue](transaction-queue.html), which means it is likely to be included in a future ledger version. [New in: rippled 1.5.0][] | | `open_ledger_cost` | String | _(Omitted in sign-and-submit mode)_ The current [open ledger cost](transaction-cost.html#open-ledger-cost) before processing this transaction. Transactions with a lower cost are likely to be [queued](transaction-queue.html). [New in: rippled 1.5.0][] | -| `validated_ledger_index` | String | _(Omitted in sign-and-submit mode)_ The [ledger index][] of the newest validated ledger at the time of submission. This provides a lower bound on the ledger versions that the transaction can appear in as a result of this request. (The transaction could only have been validated in this ledger version or earlier if it had already been submitted before.) | +| `validated_ledger_index` | Integer | _(Omitted in sign-and-submit mode)_ The [ledger index][] of the newest validated ledger at the time of submission. This provides a lower bound on the ledger versions that the transaction can appear in as a result of this request. (The transaction could only have been validated in this ledger version or earlier if it had already been submitted before.) | **Warning:** Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](transaction-results.html) for details, and do not consider the transaction's results final until they appear in a validated ledger version.